Messages in this thread | | | Date | Fri, 8 Feb 2013 16:56:37 -0600 | From | Clark Williams <> | Subject | Re: Odd ENOMEM being returned in 3.8-rcX |
| |
On Fri, 08 Feb 2013 14:40:13 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote:
> Clark Williams <williams@redhat.com> writes: > > > The more I look at that the more I think I should nuke CLONE_NEWPID in > > mock. It came in with a commit that added NEWIPC, which I think is valid > > for mock managing a chroot, but we're not looking to do full-up > > containers at this point and it looks like containers is the only place > > you'd want to start a new set of pids. > > Just taking the code out seems reasonable. Howerver there is a > practical use for a pid namespace in a setup like mock. A pid namespace > makes it so your sub processes can not reparent and get away from you, > which could be handy in case someone starts a system daemon in a post > install script. >
Ok, I *think* I'm up to speed now (I'm old and slow so gimme a break).
Unsharing pidns only works after your commit in 3.8; that's why my unshare was always failing. Does it make sense for me to make an additional unshare() call with just NEWPID as an argument? That is, call unshare with the NEWNS, NEWIPC, and NEWUTS flags, then when that succeeds, try NEWPID. If the NEWPID call succeeds, do:
pid = os.fork() if pid: os.waitpid(pid, 0)
So that the child continues on?
Clark [unhandled content-type:application/pgp-signature] | |