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

[Fiedler Roman]

> 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 
....


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?

> > 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 
and container entry also to be root.root owned, which would of course 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150602/4a084c27/attachment.bin>