Quoting Pavel Emelyanov (xemul@xxxxxxxxxx): > > The way the user namespaces work right now is similar to say the IPC > > namespace - a task belongs to one user, that user belongs to precisely > > one user namespace. > > > > Even in my additional userns patches, I was changing uid to store the > > (uid, userns) so a struct user still belonged to just one user > > namespace. > > > > In contrast, with pid namespaces a task is associated with a 'struct > > pid' which links it to multiple process ids, one in each pid namespace > > to which it belongs. > > > > Perhaps we should be treating user namespaces like pid namespaces? > > I'm afraid, that I'm just starting a new thread of discussion in a > wrong place, but I can't refrain from asking "what for?" For the reasons I listed there :) > > So if I'm user 500 in what I think is the initial user namespace, I can > > create a container with a new user namespace, the init task of which is > > both uid 0 in the child userns, and uid 500 in the higher level, > > automatically giving the container access to any files I own. > > So do you mean that I can become a root, by calling clone()? You can become root in the new container. Your capabilities are meaningful only to targets (users, files) which exist in the user namespace in which you are root. It becomes more precise than the CAP_NS_OVERRIDE approach in my last patchset. > Thanks, > Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
