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. 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. Christian
