Quoting David Howells (dhowells@xxxxxxxxxx): > Serge E. Hallyn <serue@xxxxxxxxxx> wrote: > > > > I'm not sure, and that raises an interesting point. How do you alter the > > > UID and GID of keys that you're copying? You may have a set of keys with > > > different UIDs, for example. > > > > In fact that's the expectation, else why bother creating a new user > > namespace :) > > > > Ok so my preference is to keep them segragated and always empty on > > clone(CLONE_NEWUSER), and it sounds like that's the sanest thing right > > now. Please shout if I'm misunderstanding. > > I think you're misunderstanding. > > You can have, say, a keyring owned by UID 1, with three keys owned by UIDs 2, > 3 and 4, respectively, and you could be, say, running as UID 5. > > If you want to copy this keyring and these keys, do you just set the ownership > of the copies to your new UID? That might give you extra privileges. Well no, I don't want to change any ownerships. You're assuming I am UID 1 and own that keyring, right? And now I do a clone(CLONE_NEWUSER). The new task will have UID 0 and no access to any of those keys by virtue of being in a new user namespace. So now, if I as UID 1 in the parent ns had access to the data loaded into those keys, I can reload them into my new keyring. Just as I could do anyway. And if I want to, since I own the new user namespace, I can instantiate uid 2 in my new user namespace and make a key owned by UID 2. Doesn't matter. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
