Naja Melan <najame...@autistici.org> writes: > hi, > > I have been using network namespaces for a while, mostly with good results. > Recently I ran into a problem where the cgroup mount points are missing for > software that needs it (runc). > > I discovered that ip netns exec creates a mount namespace to bind mount > network configuration files. I suppose that not all mount points are > propagated to the new mount ns. Is this correct? I'm wondering if this is > intended behaviour. > > In my case this is unexpected (man page does not mention hiding mount points) > and undesired (breaks software I run in different netns). Is there a way > around this problem. > > Note that bind mounting network configuration files is not a problem in my > case, but currently I loose at least: > > - all cgroup mounts > - debugfs > - configfs > - pstore > - sysfs > - selinuxfs > - securityfs > > Is this a bug, if not is there a way to work around this?
This is mostly unexpected. The current code creates a mount namespace. Unmounts an old sysfs and mounts a new sysfs that matches your network namespace. It has to be root to do all of those things. Why you don't see the new sysfs is something I need more information to understand. Since everything else is mounted on top of sysfs. The code probably needs an update to bind mount (cgroups, debugfs, configs, pstore, selinuxfs, and securitfs) from the old sysfs to the new sysfs. That everything now gets mount points on sysfs is new from the time the code was written and the code just needs an update for that. But the we need to understand why sysfs does not show up. That sounds like a security module meddling, or possibly an attempt to run ip netns exec in a user namespace. Eric
