[OpenAFS-devel] [LKML] Re: In-kernel Authentication Tokens (PAGs)

[Jeffrey Hutzelman]

On Tuesday, July 13, 2004 21:12:05 -0400 Kyle Moffett <mrmacman_g4@mac.com> 
wrote:

> 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 wrote
>>> In the current proposal which I believe Kyle Moffett is coding up
>>> right now, setuid() and co. don't do anything with the keyrings.
>> Is that correct? What's the plan?
>
> 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