public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug nptl/17214] Expose a function to reset the PID cache Date: Thu, 31 Jul 2014 23:25:00 -0000 [thread overview] Message-ID: <bug-17214-131-eyZQ7S3Jh9@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-17214-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-07-31 23:25 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-29 21:23 [Bug nptl/17214] New: " sstewartgallus00 at mylangara dot bc.ca 2014-07-30 4:07 ` [Bug nptl/17214] " carlos at redhat dot com 2014-07-30 17:39 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-30 17:41 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-31 23:25 ` carlos at redhat dot com [this message] 2014-08-01 21:59 ` sstewartgallus00 at mylangara dot bc.ca 2014-08-26 4:38 ` bugdal at aerifal dot cx 2014-08-26 18:11 ` sstewartgallus00 at mylangara dot bc.ca 2014-08-26 18:31 ` sstewartgallus00 at mylangara dot bc.ca 2014-10-30 22:01 ` rickyz at chromium dot org 2014-12-18 0:15 ` jld at mozilla dot com 2014-12-18 23:58 ` [Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one sstewartgallus00 at mylangara dot bc.ca 2014-12-19 0:13 ` sstewartgallus00 at mylangara dot bc.ca 2014-12-19 1:17 ` bugdal at aerifal dot cx 2014-12-19 20:29 ` sstewartgallus00 at mylangara dot bc.ca 2014-12-19 21:01 ` bugdal at aerifal dot cx 2015-01-26 22:33 ` sstewartgallus00 at mylangara dot bc.ca
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17214-131-eyZQ7S3Jh9@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).