request-key vs pipefs

[Benjamin Coddington]

Trond Myklebust wrote:
> 
> gssd doesn't use keyrings. It looks for the user's kerberos tgt inside
> the /tmp/tktp* file.
> 
>> Presumably, the information needed to create the context would still be 
>> around to renew the context -- such as a default krb5 key in the 
>> original caller's keyring.  Couldn't context keys contain or be named 
>> with this caller's keyring key_serial where the identifying information 
>> was originally found, so that it could be used to refresh the context?
> 
> Keyrings are by design not meant to be accessible to other processes
> whether or not they know the key_serial. Finding a secure solution that
> doesn't compromise this basic design has been one of the main reasons
> for the delay.
> 
>   Trond

Maybe I don't understand correctly... but when the context is originally 
created, doesn't the creator have access to everything needed, and can 
use it later to renew a context?

For example: process A calls sys_write(), auth_gss does request-key 
which execs "gss-util" sending an authkey.  "gss-util" uses authkey to 
search process A's keyrings for a krb key (ticket location.. ticket..), 
then uses this to create the context.  The context is put into the 
requested key and returned to process A..  Now later, an async discovers 
the context is expired, and does request-key -- but "gss-util" knows 
this is a refresh (either request-key callout_info, or context match) 
and knows where the TKT can be found to refresh the context.

~Ben