[Bug nptl/17214] Expose a function to reset the PID cache

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17214

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Steven Stewart-Gallus from comment #2)
> Doing unshare(CLONE_NEWPID | CLONE_NEWUSER) and then a fork doesn't
> work because it leaves the parent process unable to use multiple
> threads afterwards. It also can't use multiple threads in
> initialization because of a race condition where pthread_join doesn't
> wait until a thread is completely and totally destroyed (only almost
> completely I think). I think I could loop at this point until I get a
> succesful fork but this is also kind of ugly.

The problem is that you're using clone directly. From the perspective of the
implementation you've just looked behind that curtain, and we don't support
user code calling clone.

Having said that, we are trying hard to understand the individual use cases for
using clone to see if there is anything we can do to help provide a unified API
that coordinates with threads and TLS.

Why does clone(CLONE_NEWPID|CLONE_NEWUSER)+fork leave the process unable to use
multiple threads afterwards?

What race condition is there in pthread_join?

> As a result, I'm now virtualized as having really strong privileges
> with possibly the wrong PID in the cache and I need to setup my
> sandbox by mounting and unsharing a bunch of stuff. I actually wanted
> to exec (which would also reset the PID cache obviously) at this point
> to a utility program to setup my sandbox but unfortunately
> capabilities get dropped after an exec so I have to keep executing
> after the clone. So now I need to do general purpose init or systemd
> like code after the clone to setup my sandbox. I could hard code
> process 1 in all of my code but I need to call into library code which
> does things like use getpid (there are a few threading things which
> use getpid).

I expect that you are not doing this with threads running. If you clone after
having created a thread the userspace thread structure will still holds the old
tid, and we use that for various purposes (locking, signaling, threaded
forking) which are now wrong in the currently new PID namespace.

> Currently I work around this by forking again and just having PID 1 be
> a simple init and PID 2 being systemd or OpenRC. Unfortunately, this
> is hacky because it opens up the security problem of an attacker
> ptracing PID 1 (which hasn't sandboxed itself because it is just a
> simple init) and escaping the sandbox. I can then work around that by
> setting PID 1 not dumpable but I dislike losing my ability to ptrace
> things. Also it might not be a smart idea to have my monitor process
> (PID 2) able to receive signals by attackers.

Exit from the first task (PID 1) and leave the child (PID 2) running?

> Another possible workaround is to use /proc/self/uid_map and
> /proc/self/gid_map and setuid and setgid to different privileges after
> init which seems like the right approach to me. Unfortunately, my user
> space still hasn't rolled out the changes needed for me to have
> multiple users in my VM (unless I start out as root which is another
> barrel of problems).

Fragile.

> My code works without having a method to reset the PID cache but I
> think with such a method it would be much simpler and more robust.

I don't disagree and this problem has come up once before from the linux
containers people who have to do odd things to work around the issue.

I've emailed the lxc to ask them what they did.

-- 
You are receiving this mail because:
You are on the CC list for the bug.