> ... Eric W. Biederman wrote: > Now it probably needs to be better documented that /proc/*/net/* > have the same inode number if the network namespace is the > same, as everyone including myself overlooked this very handy > existing property. Eh, so did I. But, yes, very nice. On Sat, May 21, 2011 at 05:15:38PM -0700, Eric W. Biederman wrote: > Additionally that solution will work for comparing network namespaces > that don't happen to have any processes in them at the moment. Because > fstat works on file descriptors. Hm. I have a peeve here. Assume I am a... rogue admin, whatever. I have root on a router. I create a new network namespace, put a macvlan of eth0 in it and a macvlan of eth1. I enable ip_forward. Then I make a mount namespace, bind-mount the net namespace, bind mount the mount namespace and terminate all processes that reference it (yes this does work, i just checked [!]). Now I can use it to bypass all firewall rules, IDS, whatever. How is any normal admin, monitoring script or whatever else able to detect this? > With the /proc/<pid>/ns/net file and bind mounts I have solved the > deeper problem of how do we get userspace policy into the naming of > namespaces. With those files and the setns system call I have solved > the other problem of what is a good way to refer to namespaces without > assuming a global name. So once those changes are merged I expect there > to be much less pressure to misuse any kind of identifier we can have. > > And if we only make the guarantee about inode consistency for the > /proc/<pid>/ns/FILE files I don't expect it will make maintenance > of procfs any harder than it already is. -David _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers