[lxc-users] /dev/random problem with unprivileged minimal containers

[Serge Hallyn]

Quoting Fiedler Roman (Roman.Fiedler at ait.ac.at):
> > Von: lxc-users [mailto:lxc-users-bounces at lists.linuxcontainers.org] Im 
> > Auftrag
> >
> > Quoting Fiedler Roman (Roman.Fiedler at ait.ac.at):
> > > Hello  List,
> > >
> > > I've tried to create a unprivileged minimal container from scratch just
> > > writing config and extracting minimal guest tar to root with correct
> > > UIDs/GIDs.
> > >
> > > Most things work fine, but SSH failed to start:
> > >
> > > # /usr/sbin/sshd -D
> > > PRNG is not seeded
> > >
> > > Cause was that /dev/random is missing.
> > >
> > > Question: at what point guest /dev/random would be created? Is this done
> > by
> > > LXC, has it be triggered on host side or is just permission given on host
> > > side but creation is done by guest udev or similar?
> > >
> > >
> > >
> > > My lxc-config contains those entries:
> > >
> > > # /dev/random
> > > lxc.cgroup.devices.allow = c 1:8 rwm
> > > # /dev/urandom
> > > lxc.cgroup.devices.allow = c 1:9 rwm
> >
> > Did you add 'lxc.autodev = 1' to your configuration?  If autodev is set,
> > then fill_autodev should be creating /dev/random at start time.
> 
> No, I had to deactivate it to get it running with unprivileged containers. 
> Otherwise error would be
> 
> # lxc-start -n test lxc-start: conf.c: mk_devtmpfs: 1318 Permission denied - 
> Unable to create /dev/.lxc for autodev
> lxc-start: conf.c: setup_autodev: 1521 Operation not permitted - Error 
> creating null
> lxc-start: conf.c: lxc_setup: 4191 failed to populate /dev in the container 
> ....

Note that if you want to use autodev, you can create the /dev/lxc by hand
with the appropriate perms (see the postinst script for one of the packages
for an example).

> 
> 
> But thanks to your comment, you brought me on the right track: yes, the 
> devices have to be copied or bind mounted to the rootfs/dev before startup 
> manually or by script
> 
> > > After calling
> > >
> > > lxc-device -n test add /dev/random /dev/random
> > > lxc-device -n test add /dev/urandom /dev/urandom
> > >
> > > the devices exist in guest but with wrong uid/gid and wrong permissions
> > > (perhaps my version of lxc-device does not play nice with unprivileged)
> >
> > Because you are unprivileged, you cannot create /dev/random.  All you can
> > do
> > is to bind mount it from the host.  So it gets the same uid/gid/perms as
> > on the host.
> 
> For unique devices like /dev/ttyUSB... I agree. If the driver uses the dev 
> inode in some way, duplication might have side effects.
> 
> For other devices like /dev/random, is there any significant difference 
> between bind mounting and duplicating it?

Since you are not using lxc.autodev, you have a persistent /dev, so if you
have root access on the host then you can go ahead and do this.  But root
in a user namespace cannot create devices.  So without becoming host-root
this is not an option.

> > > host# ls -al /dev/random
> > > crw-rw-rw- 1 root root 1, 8 Apr 22 09:32 /dev/random
> > >
> > > container# ls -al /dev/random
> > > crw-r--r-- 1 nobody nogroup 1, 8 Jun  2 12:22 /dev/random
> >
> > So that's precisely what I'd expect, since root/root is not mapped into the
> > unprivileged container.
> 
> Well, I cannot completely second that: I would expect mode 0666 for both nodes 

But it's simply mirroring what you have on the host.  On mine, in fact, I have

root at precise-gui:/# ls -l /dev/random
crw-rw-rw- 1 nobody nogroup 1, 8 May 28 09:48 /dev/random

Oh, or if it's not bind-mounted, then you just need to chown it yourself.

> and container entry also to be root.root owned, which would of course 

You can set it up that way yourself by becoming root on the host, mknod'ing
the device in the container's /dev, and chowning it to your container root uid.

But when it is bind-mounted, then there is no way to make it
container-root.root owned.

> correspond to other uid/gid on host. This should have less security/regression 
> impact in that case as host user has "rw" on host device already, being owner 
> should not change much (security) and inside guest other processes see it as 
> uid 0/0, so if they have some sanity checking code  that might trigger on 
> nobody/nogroup, that could be avoided this  way.

..  I guess you said you created the minimal-priv container from scratch.  Which
means you somehow filled in that /dev.  I agree that making it root:root and
wider perms would be fine.  Just go into .local/share/lxc/$name/rootfs/dev
and make the changes you want.

If you run lxc-device by hand as an unprivileged user, it can only do the
bind mount method.  If you run it as root for a privileged container, it
doesn't need to uid-shift.  If you run it as root for a root-owned unprivileged
container, then it *should* uid-shift, but it currently will not.  (This is
another in a lis tof ways in which root-owned unprivileged containers have
gotten less attention than other types, just bc ppl haven't really used them
much)

A patch for that would be very welcome, and shouldn't be difficult - you'd
probably do it in src/lxc/lxccontainer.c:do_add_remove_node(), and you'd
have to pass the c->lxc_conf into do_add_remove_node()
from add_remove_device_node().

-serge