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

["sstewartgallus00 at mylangara dot bc.ca" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc.ca> ---
Sure I'd love to explain more about my problem.

First I'm experimenting with sandboxing my program by using clone and
CLONE_NEWUSER and CLONE_NEWPID.

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.

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).

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.

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).

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.

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