"Serge E. Hallyn" <serue@us.ibm.com> writes:

quoted text
> Earlier I had thought this could just be done using a special keyring,
> but atm I'm thinking that would be far uglier than just having a
> struct pid-like credential proxy in the kernel to pass around in place
> of uids.

I have not looked at many of the implementation possibilities so unfortunately
I don't know what makes for a good implementation.

What I do know is that uids are serialized in filesystems, and their
mapping between namespaces is defined by system administrators.

Both of those properties are different from struct pid.  Which means
a generalized struct user in the kernel can at best hold a cache of the
mappings.

My preliminary investigations suggested that for the kernel filesystem
boundary generating a struct user or a struct group just to use for a
permission check and then to throw it away was wasteful.

However for inkernel entities a struct user sounds practical.

All of which is to say that we can learn lessons from the
implementation of struct pid but that we also have different
requirements so we can only use those lessons in a limited fashion.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html