"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. 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. Eric -- 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
