Christian Brauner <christian.brauner@xxxxxxxxxx> writes: > On Mon, Aug 17, 2020 at 10:48:01AM -0500, Eric W. Biederman wrote: >> >> Creating names in the kernel for namespaces is very difficult and >> problematic. I have not seen anything that looks like all of the >> problems have been solved with restoring these new names. >> >> When your filter for your list of namespaces is user namespace creating >> a new directory in proc is highly questionable. >> >> As everyone uses proc placing this functionality in proc also amplifies >> the problem of creating names. >> >> >> Rather than proc having a way to mount a namespace filesystem filter by >> the user namespace of the mounter likely to have many many fewer >> problems. Especially as we are limiting/not allow new non-process >> things and ideally finding a way to remove the non-process things. >> >> >> Kirill you have a good point that taking the case where a pid namespace >> does not exist in a user namespace is likely quite unrealistic. >> >> Kirill mentioned upthread that the list of namespaces are the list that >> can appear in a container. Except by discipline in creating containers >> it is not possible to know which namespaces may appear in attached to a >> process. It is possible to be very creative with setns, and violate any >> constraint you may have. Which means your filtered list of namespaces >> may not contain all of the namespaces used by a set of processes. This > > Indeed. We use setns() quite creatively when intercepting syscalls and > when attaching to a container. > >> further argues that attaching the list of namespaces to proc does not >> make sense. >> >> Andrei has a good point that placing the names in a hierarchy by >> user namespace has the potential to create more freedom when >> assigning names to namespaces, as it means the names for namespaces >> do not need to be globally unique, and while still allowing the names >> to stay the same. >> >> >> To recap the possibilities for names for namespaces that I have seen >> mentioned in this thread are: >> - Names per mount >> - Names per user namespace >> >> I personally suspect that names per mount are likely to be so flexibly >> they are confusing, while names per user namespace are likely to be >> rigid, possibly too rigid to use. >> >> It all depends upon how everything is used. I have yet to see a >> complete story of how these names will be generated and used. So I can >> not really judge. > > So I haven't fully understood either what the motivation for this > patchset is. > I can just speak to the use-case I had when I started prototyping > something similar: We needed a way to get a view on all namespaces > that exist on the system because we wanted a way to do namespace > debugging on a live system. This interface could've easily lived in > debugfs. The main point was that it should contain all namespaces. > Note, that it wasn't supposed to be a hierarchical format it was only > mean to list all namespaces and accessible to real root. > The interface here is way more flexible/complex and I haven't yet > figured out what exactly it is supposed to be used for. > >> >> >> Let me add another take on this idea that might give this work a path >> forward. If I were solving this I would explore giving nsfs directories >> per user namespace, and a way to mount it that exposed the directory of >> the mounters current user namespace (something like btrfs snapshots). >> >> Hmm. For the user namespace directory I think I would give it a file >> "ns" that can be opened to get a file handle on the user namespace. >> Plus a set of subdirectories "cgroup", "ipc", "mnt", "net", "pid", >> "user", "uts") for each type of namespace. In each directory I think >> I would just have a 64bit counter and each new entry I would assign the >> next number from that counter. >> >> The restore could either have the ability to rename files or simply the >> ability to bump the counter (like we do with pids) so the names of the >> namespaces can be restored. >> >> That winds up making a user namespace the namespace of namespaces, so >> I am not 100% about the idea. > > I think you're right that we need to understand better what the use-case > is. If I understand your suggestion correctly it wouldn't allow to show > nested user namespaces if the nsfs mount is per-user namespace. So what I was thinking is that we have the user namespace directories and that the mount code would perform a bind mount such that the directory that matches the mounters user namespace is the root directory. > Let me throw in a crazy idea: couldn't we just make the ioctl_ns() walk > a namespace hierarchy? For example, you could pass in a user namespace > fd and then you'd get back a struct with handles for fds for the > namespaces owned by that user namespace and then you could use > NS_GET_USERNS/NS_GET_PARENT to walk upwards from the user namespace fd > passed in initially and so on? Or something similar/simpler. This would > also decouple this from procfs somewhat. Hmm. That would remove the need to have names. We could just keep a list of the namespaces in creation order. Hopefully the CRIU folks could preserve that create order without too much trouble. Say with an ioctl NS_NEXT_CREATION which takes two fds, and returns a new file descriptor. The arguments would be the user namespace and -1 or the file descriptor last returned fro NS_NEXT_CREATION. Assuming that is not difficult for CRIU to restore that would be a very simple patch. Eric
