Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > > 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? > > > > For autofs this would mean that when autofs wants a uid for some task, > > it would be given the uid in the user namespace which autofs 'knows'. > > > > It would also help me fix the siginfo problems I haven't solved yet - > > rather than having to worry about user namespace lifetimes with siginfos > > (which last a little while but have no clearly defined lifespan) we > > could send the uid in an init user namespace or the uid in the target > > uid namespace, or just a lightweight user struct proxy akin to 'struct > > pid'. > > > > And it also obviates the need for any sort of delegation. > > > > 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. > > > > Eric, when you get a chance (I know you're overloaded atm) I'd love to > > hear your thoughts on this... > > Succinctly. > > I think the concept of mapping uids between user namespaces is > fundamental to properly describing and thinking about the semantics of > user namespaces correct. Earlier I had thought this could just be done using a special keyring, but atm I'm thinking that would be far uglier than just having a struct pid-like credential proxy in the kernel to pass around in place of uids. > We don't have to start out anything except handling the case when > no mapping exists, but asking the question how does this uid map > between from one namespace to another is fundamental. True. But in any case I'm happy letting other things like netns and related sys be completed before prototyping this. thanks, -serge -- 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
