Since nobody else responded, even though I don't use this environment... > Host OS: Debian Wheezy > VM: Debian Wheezy
Here's the issue: > INIT: version 2.88 booting > /etc/init.d/rc: 424: /lib/lsb/init-functions: cannot create /dev/null: > Permission denied > /etc/init.d/rc: 85: /etc/init.d/rc: cannot create /dev/null: Permission > denied > mount: permission denied > /etc/rcS.d/S02hostname.sh: 424: /lib/lsb/init-functions: cannot create > /dev/null: Permission denied > hostname: you must be root to change the host name > /etc/rcS.d/S02mountkernfs.sh: 424: /lib/lsb/init-functions: cannot create > /dev/null: Permission denied The above is your distribution init scripts trying to create devices within the guest filesystem. There are two ways around this: 1) Pre-create them (GOOD IDEA) 2) Grant it the rights to create them (BAD IDEA) Solution (1) can probably be achieved with careful use of cp from the host, or lots of fussy `mknod` use. There are also probably ways to do this with various device-oriented filesystems, but it's best in both a security and portability sense to use static device files instead. For solution (2), which is a BAD IDEA due to the fact that the capability in question (`man capabilities`, CAP_SYS_ADMIN) simultaneously allows device creation *and* lots of really bad stuff that you don't want an attacker who gets root in your container to do, the specific line that disallows the guest from creating the devices is: > lxc.cap.drop = sys_admin Again, my advice is: don't change this line. You were probably confused with the following lines which, in my understanding, define a sort of whitelist of device access from within the container without necessarily caring whether said devices actually exist within the guest filesystem (a separate issue). To clarify: the above line disallows device creation on the filesystem, the below two lines deal with device access. > lxc.cgroup.devices.allow = c *:* rwm > lxc.cgroup.devices.allow = b *:* rwm If you are interested in using containers in anything like a production environment I would suggest reviewing the generated configuration of `gentoo-lxc`, which contains some gathered wisdom around functional levels of security. It begins at https://github.com/globalcitizen/lxc-gentoo/blob/master/lxc-gentoo#L403 and includes additional recommendations to avoid mounting /sys or issuing CAP_NET_ADMIN. Enjoy, Walter ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users