> My experience with AFS is that we (well, maybe other OSs) currently shove 
> the AFS credentials in the kernel.
> 
> The problem I see with telling the AFS client to do it all itself is that 
> AFS credentials aren't really owned by a UID, they are owned by a process 
> or group of processes. The difference is that different groups of 
> processes can be owned by the same UID. Just because one (group of) 
> process(es) gain a credential does not mean that all groups belonging to 
> the same UID should have that new credential.
> 
> I just looked on the openafs web page, and I'm talking about a Process 
> Authentication Group above.
> 
> Right now, we need only keep a copy of the ID of the PAG we belong to, so 
> not much needs to happen w/ kauth.
> 
> But the reason we don't need to do much w/ kauth is that we have two 
> different credential systems in use at once, and one of them (kauth) needs 
> only hold onto references to the credentials in the other one.
> 
> The thing though is that how PAGs work seems realy sensible, and I think 
> it'd be useful to have it be part of the core kernel functionality. 
> 
> If we do add native support for PAGs, then we will need something like 
> what Jonathan was describing; one process, the credential updater, will 
> need to change the credentials for all processes in the same PAG. Thus a 
> process will need to make cred changes that all processes can see.
> 
> As an aside, I really like PAGs and would love it if our kerberos used the 
> PAG as a ticket store.

although i'm not sure if it's a good idea or not,
i don't think my proposed change prevents storing "pag id" into kauth_cred_t.
after kauth_cred_setuid() "copy-on-write" a credential, both of
new and old kauth_cred_t will keep the same "pag id".

YAMAMOTO Takashi