containers
Added --sys argument for mounting sysfs
Greetings,
I needed this feature (sysfs) for my own use-case and decided to implement it. My goal is to do networking experiments inside of a container, as well as to simply isolate / abstract different parts of my local networking setup. Most networking utilities on Linux require /sys to exist.
Mounting it after the fact is not easily possible in the upstream version: I first needed to bind-mount the host's "/sys/" to "/sys_host" via bubblewrap and only then was I allowed to mount sysfs inside the container (and only with "mount" from util-linux, not busybox!). Otherwise, I received a "VFS: Mount too revealing" from the kernel (Debian Trixie) when executing: mount -t sysfs sysfs /sys Afterwards, it is possible to unmount /sys_host and use all networking utilities.
Is there a particular reason why this feature had not been implemented? Maybe there is a security implication that I did not recognize, or it is simply not the scope of the project.
Thank you for the creation and maintenance of bubblewrap. It is a fine piece of software...!
Sincerely, Alexander Schreiber (schreiberstein)
What is the advantage of mounting a completely new instance of sysfs, instead of --[ro-]bind /sys /sys or a subset?
For example Flatpak does bwrap … --ro-bind /sys/block /sys/block, and the same for /sys/bus, /sys/class, /sys/dev and /sys/devices.
bwrap needs --proc to be a separate option (--bind /proc /proc is not enough) because when you unshare the pid namespace, the container's /proc is not the same as the host's /proc. But for any filesystem that is OK to be the same on the host and in the container, there is no need for a special option and you can just use the --{,ro-,-dev}bind{,-try} family of options.
@smcv The problem with bind mounting sysfs surfaces when dealing with networking utilities like iproute2, ifupdown, bridge-utils (brctl) because they heavily rely on sysfs being in sync with the actual network namespace. Otherwise, I will see the host's network interfaces and not the container's. This leads to unintended side-effects. For example, I can create a bridge but I cannot manage it because for the managing operation, sysfs is accessed... and my newly created bridge is not in there! Or on Alpine, when using OpenRC as init and ifupdown-ng for bringing up interfaces, it just completely errors out when configuring anything. So, I would be delighted to see that feature incorporated upstream.