[lxc-devel] Unprivileged LXC containers don't start on 4.18-rc1

Dmitrii Tcvetkov demfloro at demfloro.ru
Fri Jun 29 17:35:23 UTC 2018


On Fri, 29 Jun 2018 12:47:53 +0200
Christian Brauner <christian at brauner.io> wrote:
> On Fri, Jun 29, 2018 at 12:10:30PM +0200, Christian Brauner wrote:
> > On Fri, Jun 29, 2018 at 08:35:57AM +0300, Dmitrii Tcvetkov wrote:  
> > > Distro: Arch Linux
> > > LXC version: 3.0.1
> > > 
> > > Since 4.18-rc1 unprivileged (but started by root user) LXC
> > > containers can't start because of the error: 
> > > lxc-start test 20180629043810.254 ERROR    lxc_utils -
> > > utils.c:open_devnull:1753 - Permission denied - Can't
> > > open /dev/null  
> > 
> > I suspect this is a red herring since vfs_mknod() is not involved
> > in a call to open(). This is caused by wrong permissions and I
> > think I know how this comes about. Eric, Seth, I'm looking into
> > this.  
> 
> Ok, I was just convincing myself again that this was indeed intended
> behavior. Sorry for the delay.
> The patch we've acked and that you're referencing essentially enables
> creating device nodes in user namespaces as long as you have CAP_MKNOD
> relative to the userns of the dentry. This wasn't possible before
> 4.18-rc1. This is nice for debootstrap and other friends that just
> create device nodes but don't necessarily expect to interact with
> them. The problem stems from
> 
> static struct super_block *alloc_super(struct file_system_type *type,
> int flags, struct user_namespace *user_ns)
> {
>         /* <snip> */
> 
>         if (s->s_user_ns != &init_user_ns)
>                 s->s_iflags |= SB_I_NODEV;
> 
>         /* <snip> */
> }
> 
> on an open() call on a device node you will hit:
> 
> bool may_open_dev(const struct path *path)
> {
>         return !(path->mnt->mnt_flags & MNT_NODEV) &&
>                 !(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
> }
> 
> which will cause your EPERM because the device node is located on an
> fs owned by non-init-userns and thus sets SB_I_NODEV which means it
> won't allow access to device nodes for security reasons.
> 
> The (userspace) solution to this problem is simple. I'll have a patch
> upstream in a bit at which point we can simply track this on the LXC
> repo or lxc-devel at lists.linuxcontainers.org.
> 
> Thanks!
> Christian
> 
Thank you for looking into it. I'll try diff from the pr[1] later.

[1] https://github.com/lxc/lxc/pull/2438


More information about the lxc-devel mailing list