From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32336 invoked by alias); 30 Jul 2014 17:39:17 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 32037 invoked by uid 48); 30 Jul 2014 17:39:09 -0000 From: "sstewartgallus00 at mylangara dot bc.ca" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17214] Expose a function to reset the PID cache Date: Wed, 30 Jul 2014 17:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sstewartgallus00 at mylangara dot bc.ca X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00694.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17214 --- Comment #2 from Steven Stewart-Gallus --- 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.