On Fri, 29 Jun 2018 12:47:53 +0200
Christian Brauner <christian@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx.
>
> 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
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
