ccache using linux keyring

[David Howells]

Kevin Coffman <kwc at citi.umich.edu> wrote:

> > Can you outline the process by which you envision a service (say the NFS4
> > client in the kernel) finding a key?
> 
> Well, the NFSv4 client wants a gssapi context, not a Kerberos ticket.
> It has has no way of using a Kerberos ticket to negotiate a context
> w/o putting much more of the Kerberos code into the kernel.  So the
> NFSv4 client does a request_key for a cached gss context.  If a
> context has not already been established, then gssd is invoked to
> negotiate a context with the NFS server.  This requires gssd to
> locate the user's Kerberos credentials and, if required, obtain a
> Kerberos service ticket (using the TGT) for the target server.

/sbin/request-key now has a special construction in its session keyring that
allows it to automatically access all of the keyrings of the caller of
request_key() as if it was that process.

If /sbin/request-key then execs or forks/execs gssd then gssd will have access
to those keyrings as the original process also. However, if gssd is negotiated
with via a socket or something, then it won't have direct access; though the
client invoked directly by request-key will.

> > Not currently, but there's no reason it couldn't be made so. The quota
> > values are stored per user. What may be more limiting is that keyrings
> > currently have a hard limit of PAGE_SIZE on the content.
> 
> Is that the content of the keyring itself, or the content of all its 
> keys?

The former. The content of a keyring is an array of pointers to keys plus a
small header; the total of this must fit within one page.

David