After update openrc in my lxc container from 0.9.8.4 to 0.11.6 and reboot, network interface in container up fail with error: * Bringing up interface eth0 * ERROR: interface eth0 does not exist * Ensure that you have loaded the correct kernel module for your hardware * ERROR: net.eth0 failed to start In openrc-0.11.6 function _exists check presents interface with code: _exists() { [ -e /sys/class/net/"$IFACE" ] } but in /etc/init.d/sysfs in this version have depend() { keyword -lxc -prefix -vserver } and now /sys no populate and networks not bringing up in Linux Container. P.S. Sorry for my english Reproducible: Always
@flameeyes: My understanding is that mounting /sys inside an lxc guest is a security issue, so that is why we don't do this in OpenRC. Should we rework oldnet so that we don't depend on /sys if we can, or should I advise the user to switch over to newnet?
I guess it's your choice. It's possible, if you use net_admin, to use it without /sys — for now. My suggestion would be don't bother, if you want to use network from inside the container, you explicitly have to mount /sys on the configuration file, that works for me.
It looks like this might also be affecting vserver.
*** Bug 447866 has been marked as a duplicate of this bug. ***
Rebuilding openrc with newnet USE flag is a workaround to this bug. Is newnet still going to be removed as per this ML discussion? http://archives.gentoo.org/gentoo-dev/msg_249e5c3f56c10c86bbab3f0d8961aaf3.xml
One more thing, to properly protect against mounting /sys in the container you need to remove capability sys_admin. Without the sys_admin capability /dev, /dev/shm, /run, and /proc all need to be mounted via the config file, and init scripts making assumptions about mounting /run, /proc need to be fixed.
In an OpenVZ container, /sys is a very small subset. It can be an useful example. It appears in this way: $ tree -d /sys /sys └── class ├── mem │ ├── full │ │ └── subsystem -> ../../../class/mem │ ├── null │ │ └── subsystem -> ../../../class/mem │ ├── random │ │ └── subsystem -> ../../../class/mem │ ├── urandom │ │ └── subsystem -> ../../../class/mem │ └── zero │ └── subsystem -> ../../../class/mem ├── net │ ├── lo │ │ ├── statistics │ │ └── subsystem -> ../../../class/net │ └── venet0 │ ├── statistics │ └── subsystem -> ../../../class/net └── tty └── ptmx └── subsystem -> ../../../class/tty 22 directories The sysfs sysinit service can start, but the filesystem is created only if [ ! -d /sys ]
(In reply to comment #1) > My understanding is that mounting /sys inside an lxc guest is a security > issue, so that is why we don't do this in OpenRC. But it is still mountable from container. So there is absolutely no reasons for not mounting it automatically "for security". Because attacer can an will mount sysfs itself.
@Alexander, the container superuser cannot mount /sys if sys_admin capabilities are disabled. See the comment #6 by David.
Are Gentoo containers functional without CAP_SYS_ADMIN though? I did some limited tests and didn't get a working container without that capability.
Current state: A patch that attempted to fix a security vulnerability broke LXC containers that use "oldnet" (default networking, this file: /etc/conf.d/net). The security vulnerability still exists. I have been asked by a couple of people how to get around this breakage, the patch below is a work around. Note there is no guarantee this will work going forward so please back out this patch before updating your system. container:/etc/init.d # diff -u sysfs~ sysfs --- sysfs~ 2013-02-18 10:51:50.293058693 -0800 +++ sysfs 2013-02-18 10:52:00.063264250 -0800 @@ -6,7 +6,7 @@ depend() { - keyword -lxc -prefix -vserver + keyword -prefix -vserver } mount_sys()
@robbat2: Are you planning to rework oldnet so that it doesn't need the /sys filesystem? If not we should probably drop the oldnet tag from the whiteboard. for this bug.
This bug still exists in sys-apps/openrc-0.12.4
The reason /sys is blocked from mounting in an lxc container is fbug #425790, so I guess my question, since I do not run lxc myself, is this: In a typical lxc installation, do you need /sys to be mounted inside the container as well as on the host?
Here is a thread that discusses why we can't populate /sys inside an lxc container [1]. Does anyone have any input for this issue? [1] http://thread.gmane.org/gmane.linux.kernel.containers.lxc.devel/1402/focus=1406
> The reason /sys is blocked from mounting in an lxc container is fbug #425790, so I guess my question, since I do not run lxc myself, is this: 1) /sys is _not_ blocked from mounting in an lxc container now. It is just not mounted by init scripts. So there is no security benefit in this action. 2) As I understand that bug. The problem was: container fails to mount /sys -> init script fails by dependency on /etc/init.d/sysfs. And at the end it was workarounded by disabling /sys. It is bad, because it breaks other things without much benefit. > In a typical lxc installation, do you need /sys to be mounted inside the container as well as on the host? As for me - my containers are using network init scripts. So yes, I need /sys in container. > Here is a thread that discusses why we can't populate /sys inside an lxc container [1]. Does anyone have any input for this issue? This message have the same positions: - /sys can be mounted anyway - /sys is needed for some software - /sys is not the only such issue Also I think there is some misconception here. Because all this questions about security and what container can and can not do should be rised on the host side. This is where we need to think about it - what and how we are running. If we need somebody to not use /sys, than we should not give container such rights on the host. As other people write, this is possible to do by dropping along whith it many ohter privilleges. There can be situations, where we need that, why not? The only problem is that container environment should be able to survive in such condition. But if we want to run gentoo as full and general purpose distribution, than we are in need of such capabilities and so it is required that host do not drop it. As some software have "hardware requirements" so container software have its requirements too. I also suppose, that such great distibution as gentoo :) somebody want to use with serious restrictions from the host. OK, but this is the question that gentoo should support working in this mode and in this restrictions (may be loosing some functionality). But not shoot itself into the foot and live in self-restriction and loosing some functions. For example "working mode" can be auto-detected or configured in rc.conf. After all, we have configuration for rc_sys, and do not reduce gentoo to minimum environment common to all variants of containers and hypervisors. Also it can be some USE-flag ("-sys" for example) or special profile, to use gentoo without /sys.
Lets start a discussion on getting this fixed. Currently Gentoo doesn't run as an LXC without patching the sysfs init script. This situation seems undesirable.
