Quoting Fiedler Roman ([email protected]): > > Von: lxc-users [mailto:[email protected]] Im > > Auftrag > > > > Quoting Fiedler Roman ([email protected]): > > > 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@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 _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
