Hi! > > Since the ns_create only creates a new network namespace the rest of the > > namespaces are inherited. At least when I change the ns_create that > > creates the handle to create new user namespace as well it can > > succesfully join it. > > > > Why do we attempt to join all namespaces in the ns_exec? I guess that we > > will have to change it to get a list of namespaces to join the same way > > the ns_create does it. > > The original idea was to simply join all NSs of the target to avoid > passing the ns type, which is a nice idea and works for any other ns, > but unfortunately not for user ns. > The simple fix for that would be readlink() on the file and if the id > (dentry) matches the one in /proc/self/ns/, don't open it.
Or we may ignore EINVAL for the user namespace. But shouldn't be joining only the net namespace enough for the testing? That way we are sure that other namespaces does not cause unexpected side effects. > However I fear there may be other considerations at hand, ie. user ns > interactions with other NSs - the functions (from what I can see) can > create/unshare multiple namespaces on a single process. If one specifies > ie. CLONE_NEWNS | CLONE_NEWUSER | CLONE_NEWNET, the user ns is always > created first. This theoretically means (haven't tested it myself) that > an unprivileged user can create non-user namespaces if it has UID 0 in > the new user namespace as well as a privileged user being unable to > create the other namespaces if it doesn't have the capabilities to do so > in the new user namespace (according to uid/gid maps). Hmm, kind of makes sense... > This also implies possible complications of calling setns() multiple > times for multiple different namespace types - it may be necessary to > call it first on the user ns fd (or the other way around?). The setns() with user ns should be last if we want to join more namespaces, otherwise I get EPERM since the process is no longer capable, but that happen only in case I've actually created new user namespace. > In addition, there are probably going to be some problems with > capability bits when calling execve(2) after doing setns on user ns > (see capabilities(7), "Thread capability sets"). > > Yes, user namespaces are even bigger PITA than pid namespaces. :) Looks like that. -- Cyril Hrubis chru...@suse.cz ------------------------------------------------------------------------------ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
