"Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > > Hi Eric, > > glad you're giving this some thought. Did you ever read over the > approach which I outlined in May (see > http://forum.openvz.org/index.php?t=msg&goto=30223&;)? We agree on many > points. I think we basically solve the suid problem the same way.
I hadn't read that post although I saw a part of it in your paper. Solving that problem so unprivileged users can use a user namespace seems to be the key to making namespaces more widely usable, and recursive. Plus I really like the idea of a super nobody user. > But I've moved away from a uid-to-uid mapping. Instead, > I expand on the relation you also describe: the user who creates a user > namespace owns the user namespace and introduce a persistant > namespace ID. I think there are management issues with a persistent namespace ID. In particular: Is this user allowed to use this ID? That is the reason I want to avoid having a generic persistent namespace ID. Implementing a common library and then modifying the filesystems to use it on a case by case basis sounds much more maintainable. Then picking the wrong direction does not bind us for all time and eternity. > I understand that you may reflexively balk at introducing a new global > persistant ID when we're focusing on turning everything into a > namespace, but I think that would be a misguided reflex (like the > ioctl->netlinke one of a few years ago). In particular, in your > approach the identifier is the combination of the uid-to-uid mapping and > the uids stored on the original filesystem. Not at all. I thought I had mentioned the xattr thing as one of the possibilities. I forgot the proper term so I probably said acls. The practical problem is that you then have to rev your quota support. To also support the xattr separation. In addition not every filesystem supports xattrs. Although the common ones do. > I do think the particular form of the ID I suggest will be unsuitable > and we'll want something more flexible. Perhaps stick with the unsid > for the legacy filesystems with xattr-unsid support, and let advanced > filesystems like nfsv4, 9p, and smb use their own domain > identifiers. Which is why I said make it filesystem specific with support from a generic library. No prctl just a mount option. > But since we seem to agree on the first part - introducing a hierarchy > between users and the namespaces they create - it sounds like the > following patch would suit both of us. (I just started implementing my > approach this past week in my free time). I'm not sending this as any > sort of request for inclusion, just bc it's sitting around... Yes. At least a loose hierarchy. It just occurred to me that with unix domain sockets, some signals, /proc we have user namespace crossing (child to parent) where we need to report the uid. In that case the simple solution appears to be to use the overflowuid and overflowgid that were defined as part of the 16bit to 32bit transition. Otherwise it would require mapping all of the child uids into the parent like we do with pids except using an upcall to userspace. Making capabilities user namespace specific if we can. Did you have any problems with adding a user_namespace argument to capable? Just skimming through your patch I don't expect we will need the list of children, and not having should reduct our locking burden. Eric _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
