Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > David Howells <dhowells@xxxxxxxxxx> writes: > > > On the subject of namespaces: I still need to look at providing a key ID and > > keyring name namespace. > > > > Is it worth me just using the user_namespace? A number of parameters are > > per-UID (such as the key quotas), so it might very well make sense to do that. > > Yes. > > > That way, user_namespace could actually be a credentials namespace. > > I have always thought of it as a security token namespace. > > I'm not certain about the term credential as that usually means something > like password. In the context of keys where you are caching something > like a kerberos token it makes more sense. Even there it isn't a > secret key that is being cached but more of a capability that says > that the secret key was known at some point. > > > If that is the case, CLONE_NEWUSER should also set up (clone?) the keys and > > keyrings attached to the parent. This possibly needs to be done anyway as the > > keys have UID and GID references that may be invalid in the new namespace. > > > > How do the UIDs and GIDs in different namespaces map, anyway? > > At the simplest level they do not map between namespaces. > > At a practical level the users in a user namespace should have > no more capabilities than the creator of the user namespace and > the creator of the user namespace should have the power to kill > all processes and remove all objects created by users in that > user namespace. > > For filesystem access where we have talked about this in some detail. > The current idea is to have a user namespace parameter on struct inode. > All security credential comparisons will need to become comparisons > of both user_namespace and uid to match. > > > Furthermore, some keys may actually represent foreign user details; perhaps > > NTFS or CIFS user IDs for example. Should those be discarded on CLONE_NEWUSER? > > After CLONE_NEWUSER the user id and guid should be 0, and no keys should be > held. With respect to holding credentials it should be essentially the same > state as when init starts. At least as a general rule. > > If keys are the kind of thing that can be passed between namespaces > allowing user space to control which keys get passed makes sense. We > allow the controlling tty and process groups to remain the same across > pid namespace creation and require processes to change them explicitly > if needed. It is definitely a requirement to get to the state init > starts in, either by kernel fiat or normal user space operations. Ok so if I read this right, you're ok with either one of: 1. on clone(CLONE_NEWUSER), the new task get empty keyrings. If userspace wants the new task to have its creator's keys, it reloads them. 2. on clone(CLONE_NEWUSER), the new task gets a copy of the creator's keys. If userspace wants the new task to have an empty keyring, it can clear it. I had been thinking 2 might be easier in the face of ecryptfs, but I think 1 is the way to go. > A word about foreign user details. > > In my conception a user namespace is essentially a single administration > domain of uids and gids, and as such can span and does today span several machines. > user namespaces are unique in that their tokens are assigned administratively > and the kernel has no control over lifetime of tokens. > > In that concept foreign users doesn't make a lot of sense to me. > > Keys certainly provide the ability to several different implementations > of user identification. How that interacts with a web of administration > of user permissions to objects not living in the kernel I don't know. > > Ultimately I think putting keys in the user namespace is a good match. > As it is a way to talk about stored user identification either in memory > or on disk, and how that maps to what a user is allowed to do. > > Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers