Cc: Serge E. Hallyn <serge@...>, Eric W. Biederman <ebiederm@...>, Andrew Morton <akpm@...>, <linux-kernel@...>, Balbir Singh <balbir@...>, Serge E. Hallyn <serue@...>, <containers@...>
Ok, then that is where I was previously suggesting that we use an api to
report a uid meaningful in bob's context, where we currently (in the
absense of meaningful mount uids and uid equivalence) tell Bob that root
was the one who brought him over quota. From a user pov 'nobody' would
make more sense, but I don't think we want the kernel to know about user
nobody, right?
So if the msg weren't broadcast, or netlink sockets were tied to one
user namespace, we could call a
int uid_in_user_ns(struct user *, struct user_ns *)
sending in Alice's user struct and Bob's userns, and use the result in
the netlink message. Otherwise I'm not sure what is the right answer.
We just might need the equivalent of 'struct pid' to struct user, or
persistant global user namespace ids (persistant after user namespace
destruction, not across reboot) so we can safely send the user_ns * in a
netlink msg.
I think that's ok.
Hopefully when that changes to accomodate user namespaces, we can use
netlink field versioning to make that transition pretty seamless?
If not, then we probably should in fact make some decision now so as not
to change the api.
What is the ordinary user going to do about it? If the user didn't set
up the nfsserver and/or the second client, the only thing he can do is
report the guilty user to an admin. In which case the tuple
(host=nfsserver,uid=1000) is exactly the data he needs to report.
thanks,
-serge
-
