[lxc-devel] Howto user namespaces?

richard -rw- weinberger richard.weinberger at gmail.com
Wed Apr 10 18:42:10 UTC 2013


On Tue, Apr 9, 2013 at 11:33 PM, richard -rw- weinberger
<richard.weinberger at gmail.com> wrote:
> On Tue, Apr 9, 2013 at 11:07 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>> Quoting richard -rw- weinberger (richard.weinberger at gmail.com):
>>> On Tue, Apr 9, 2013 at 3:19 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>>> > Quoting richard -rw- weinberger (richard.weinberger at gmail.com):
>>> >> On Tue, Apr 9, 2013 at 9:58 AM, richard -rw- weinberger
>>> >> <richard.weinberger at gmail.com> wrote:
>>> >> > On Tue, Apr 9, 2013 at 5:28 AM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>>> >> >> Quoting richard -rw- weinberger (richard.weinberger at gmail.com):
>>> >> >>> Am I missing something obvious?
>>> >> >>
>>> >> >> lxc-create does not yet convert the rootfs to the mapped uids, so you
>>> >> >> need to do that manually using uidmapshift.  Check the
>>> >> >> container-userns-convert script at
>>> >> >> https://code.launchpad.net/~serge-hallyn/+junk/nsexec or in the nsexec
>>> >> >> package at ppa:serge-hallyn/userns-natty.
>>> >> >
>>> >> > Hmm, I've fixed the uids already by hand.
>>> >> > Today I've created a new container and used container-userns-convert
>>> >> > but with the same results.
>>> >> >
>>> >> > What I find very strange is that your script does:
>>> >> > lxc.id_map = U ${uid} 0 $range
>>> >> > lxc.id_map = G ${uid} 0 $range
>>> >> > uid is 100000, range is 10000.
>>> >> >
>>> >> > But the lxc docs say:
>>> >> >               Four values must be provided.  First a character, either
>>> >> >               'u', or 'g', to specify whether user or group ids are
>>> >> >               being mapped.  Next is the first userid as seen in the
>>> >> >               user namespace of the container.  Next is the userid as
>>> >> >               seen on the host.  Finally, a range indicating the number
>>> >> >               of consecutive ids to map.
>>> >> >
>>> >> > So, this would make more sense: lxc.id_map = u 0 100000 10000
>>> >> >
>>> >> > Anyways, mount of tmpfs fails with ENOPERM, is there any debugging
>>> >> > mechanism to find out why it is failing?
>>> >> > According to strace some bind mounts before the tmpfs work perfectly fine.
>>> >>
>>> >> BTW: I found out that tmpfs is not supported within user namespaces...
>>> >
>>> > It should be in 3.9:
>>> >
>>> >     userns: Allow the userns root to mount tmpfs.
>>>
>>> Okay. Mounting tmpfs works on 3.9 so far.
>>>
>>> >> Anyways, now lxc-start dies here:
>>> >> lxc-start: Operation not permitted - failed to set mode '020644' to '/dev/pts/1'
>>> >> which is:
>>> >> chmod("/dev/pts/1", 020644) = -1 EPERM (Operation not permitted)
>>> >> Shouldn't this be /usr/lib64/lxc/rootfs/dev/pts/1?!
>>> >
>>> > Look at Eric's user namespaces kernel tree for patches which aren't in
>>> > your tree yet.  (I also have one, but right now it is out of date with
>>> > respect to some recent fixes Eric has sent upstream.)  Upstream is
>>> > almost 100% there, but an <eensie weensie> bit away.
>>>
>>> Which tree is that?
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
>>> for-linus (and for-next)
>>> differ only by one commit:
>>> proc: Restrict mounting the proc filesystem
>>
>> you'll probably have better luck with branch userns-always-map-user-v100
>
> Nope. Same result.
> FWIW to build userns-always-map-user-v100 on current Linus tree the
> following patch is needed:
> ---
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index f0f0faa..ecfd846 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -386,8 +386,8 @@ struct vfsmount *devpts_mntget(struct file *filp)
>         struct vfsmount *mnt = ERR_PTR(-ENODEV);
>
>         /* Verify the mnt is a devpts mount */
> -       if (filp->f_vfsmnt->mnt_sb->s_magic == DEVPTS_SUPER_MAGIC)
> -               mnt = mntget(filp->f_vfsmnt);
> +       if (filp->f_path.mnt->mnt_sb->s_magic == DEVPTS_SUPER_MAGIC)
> +               mnt = mntget(filp->f_path.mnt);
>         return mnt;
>  }
> ---
>
>> The unsafe kernel (until I get time to update it) which definately works
>> is in ppa ubuntu-lxc/kernel.

This one?
https://launchpad.net/~ubuntu-lxc/+archive/kernel/+packages

I'm not an Ubuntu guy and not very familiar with this ppa thingy.
Isn't there a git repo to find out what the differences between mainline are?

--
Thanks,
//richard




More information about the lxc-devel mailing list