Please CC me, I am not on OpenAFS-devel
On Jul 13, 2004, at 11:37, Tomas Olsson wrote:Hi, on the openafs-devel list, John Bucy wroteIs that correct? What's the plan?In the current proposal which I believe Kyle Moffett is coding up right now, setuid() and co. don't do anything with the keyrings.
The proposal I am working on does not currently need to add additional logic to any existing sys-calls. It merely associates additional data with certain contexts: Thread Process Process-Group Session UID GID
Each of these objects will have an additional pointer to a key (A key-ring is just a special case of a key that has sub-keys). When something (EG OpenAFS), requires tokens of a particular type for a particular realm, it performs a generic search using a kernel function. That search looks through each of the above in order. If a key is a key-ring, first all keys of the specified type are checked, then all nested key-rings, in arbitrary order.
OK, but what's a "key" ?
What value do I get to use to associate authentication context with things like credentials, cached connections, rights metadata, and so on? Bear in mind that these structures are not only fairly complex, but may belong to a user-mode process. So, it won't work to just make them be part of the "key".
Basically, I need some sort of label I can use in these structures. It must be the case that the meaning of a particular value of that label cannot change without my receiving a notification, so I don't end up with a cached connection established with one user's credentials that is labelled with a label that now belongs to another user. Similarly, it is important to have notification when the credentials themselves change -- if you set a new token, I need to throw away cached connections established with the old token.
It also must be the case that a user cannot "forge" a label.
So, it pretty much has to be a kernel-defined property of the key, rather than a user-supplied value.
If you think your stuff meets these requirements, then I suppose I should take a look and see how hard it would be to actually use it.
-- Jeff
-- Jeff _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
