Re: Odd ENOMEM being returned in 3.8-rcX

[Clark Williams <williams@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]