NAK: user namespace delta for raring?

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at canonical.com> writes:

> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> Serge Hallyn <serge.hallyn at canonical.com> writes:
>> 
>> > Quoting Serge Hallyn (serge.hallyn at canonical.com):
>> >> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> >> > A big chunk of my devpts patches are to resolve the newinstance
>> >> > /dev/ptmx mess.  I forget all of the details of why that is a problem.
>> >> > How to sort out that mess is a problem, substantial and maybe a little
>> >> > controversial.
>> >> > 
>> >> > The basics of allowing devpts to be mounted with user namespace
>> >> > permissions should be a trivial few additional lines of code.
>> >> 
>> >> There certainly are weirdnesses - in particular that 'mount -t devpts'
>> >> without newinstance, even after mounting a newinstance, will get you
>> >> the init devpts instance back.  And that the /dev/ptmx device, if not
>> >> bind-mounted from /dev/pts, gets you the host instance.  But we work
>> >> around the former by refusing devpts mounts in the container altogether
>> >> using apparmor (not ideal, but works), and the latter, of course by
>> >> bind-mounting /dev/pts/ptmx.
>> >> 
>> >> So while those address a real problem that would be good to have
>> >> fixed, you might be right that we might be able to drop them.  I
>> >> could test a kernel without those patches and see if there is some
>> >> issue I'm forgetting that prevents containers from starting.
>> >
>> > Woohoo - yes, using a kernel from
>> > git://kernel.ubuntu.com/serge/quantal-userns.git branch
>> > master-next.jan14.userns.shortened, I can still run ubuntu containers
>> > in a userns just fine.  This has the following patches removed:
>> >
>> > linux (3.8.0-0.1userns2) raring; urgency=low
>> >
>> >   * Remove some patches:
>> >     - 5cc374f: proc: Kill dead code in proc_fill_cache
>> >     - 9dac985: vfs: Fix weird nfs revalidate problem.
>> >     - d4853ad: devpts: Remove unnecessary compatibility code
>> >     - 09e8dc6: devpts: Update the documentation
>> >     - 7736dad: devpts: Remove the internal mount.
>> >     - cb1917a: devpts: kill pts_sb_from_inode
>> >     - 5285622: devpts: Remove the devpty cleanup special case.
>> >     - 58cbf60: devpts: Rename /dev/ptmx /dev/pts/ptmx
>> >     - 02ae468: devpts: Make ptmx a symlink to pts/ptmx on devtmpfs
>> >     - 753aaf4: devpts: Make the newinstance option historical
>> >     - 03c7dff: devpts: Remove CONFIG_DEVPTS_MULTIPLE_INSTANCES
>> >     - 9bc0f7d: devpts: Set the default permissions of /dev/pts/ptmx and /dev/ptmx to 0666
>> >
>> >  -- Serge Hallyn <serge at tangerine.buildd>  Fri, 18 Jan 2013 20:24:11  +0000
>> 
>> Serge you should be able to drop the following patches.  They are all
>> experimental patches you should not need.  I think you and I were
>> talking about different things when you asked me about quota support. 
>> 
>> userns: Add a user namespace parameter onto the superblock
>> userns: Make quota usable by filesystems outside the initial userns.
>> ext2: Add support for unprivileged mounts
>> userns: Allow for fuse filesystems outside the initial user namespace
>> fuse: Teach fuse how to handle the pid namespace.
>> userns: fuse unprivileged mount suport
>> fuse: Only allow read/writing user xattrs
>> net: Allow opening an af_unix socket
>
> Yup, that still is working. 

Good.  I am glad that things still work with those patches dropped.
That reduces the set of interesting patches a lot.

> I expected net: Allow opening an af_unix
> socket to break something, but I was able to login at least.  However I
> did notice that I couldn't, as root logged into /dev/tty1 of a
> container, do ls -l /proc/$pid/fd for the pid of a root login onto
> /dev/console.  I'm not sure if that used to be the case of not.

The patch "net: Allow opening opening an af_unix socket" is part of the
conversation about how to let nfs mounts work inside of containers.
While allowing a normal open on an af_unix socket in the filesystem is a
nice idea nothing turned out to actually need it.

How does ls -l /proc/$pid/fd fail for the pid of a root login onto
/dev/console?   That just sounds weird.

Eric