NAK: user namespace delta for raring?

Serge Hallyn serge.hallyn at canonical.com
Fri Jan 18 05:42:20 UTC 2013


Quoting Eric W. Biederman (ebiederm at xmission.com):
> Serge Hallyn <serge.hallyn at canonical.com> writes:
> 
> > Quoting Tim Gardner (tim.gardner at canonical.com):
> >> On 01/16/2013 04:21 PM, Serge Hallyn wrote:
> >> >Hi,
> >> >
> >> >The bulk of Eric's user namespace patches were accepted into 3.8.
> >> >The remainder are mainly updates to devpts and some kuid fixups for
> >> >various filesystems.  A raring tree with those patches pushed on
> >> >top is at
> >> >
> >> >http://kernel.ubuntu.com/git?p=serge/quantal-userns.git;a=summary
> >> >
> >> >Most of the additional patches come from Eric's tree, though a
> >> >few are fixups for Ubuntu delta, plus a patch of mine to allow
> >> >tmpfs mounts in user namespaces.
> >> >
> >> >With that kernel, I can run lxc containers in private user
> >> >namespaces.
> >> >
> >> >Would it be possible to carry these patches as an Ubuntu delta
> >> >in raring?
> >> >
> >> >thanks,
> >> >-serge
> >> >
> >> 
> >> I'm quite reluctant to carry these patches. I think they need a
> >> bunch of maintainer approvals yet, and definitely some bake time in
> >> linux-next (if they haven't already). I'd be a lot more willing to
> >> consider them as cherry-picks or backports from the 3.9 merge. What
> >> you are proposing appears to have deep and substantive internal
> >> behavioural changes that will be extremely difficult for anyone on
> >> my team to debug in the event of error.
> >
> > That's too bad, but thanks.
> >
> > (The patches with subject 'userns: Convert <...>' are not deep
> > substantive changes, but the devpts ones are, and without those
> > we still wouldn't have enough to use user namespace with ubuntu
> > system containers.)
> 
> I will start a final review and pushing these things into linux-next
> shortly.  Certainly a lot of my filesystem conversion to kuid and kgid
> patches need to be broken up into smaller patches so it is clear they
> are simple and obviously correct.
> 
> To help me prioritize things are there any of the remaining filesystem
> that I have patches for that Ubunutu does not build?  Perhaps you don't
> care about xfs?

I'm afraid all of the ones yet to be merged from your tree are compiled.
Even coda gets compiled (as a module)!  :)

> The basic devpts change is about like the tmptfs change a single line.
> 
> The tricky part with devpts is figuring where to modify userspace so
> that /dev/pts is mounted with the newinstance options in a container
> isn't it?  Since udev doesn't create device nodes not creating making
> /dev/ptmx a symlink to /dev/pts/ptmx should not be a problem.  Serge are
> there useful containers you can build that can use the newinstance
> mount option of /dev/pts?

Sorry I'm missing something...  all of the containers we normally create
use a newinstance mount option for their own /dev/pts, mounted by the
child in the new user namespace.  (They also inherit, for /dev/ttyN,
ptys from the parent devpts mount.  Those get chowned to the mapped ids
for root:tty to handle the userns)

> I don't plan to drop any of my work in my queue but if we router around
> some of the parts that need lots of reivew that would be great.

I wonder if we can delay some of the quota stuff.

-serge




More information about the kernel-team mailing list