ccache using linux keyring

[Kevin Coffman]

> Kevin Coffman <kwc at citi.umich.edu> wrote:
> 
> > I chose session because that what seemed more pag-like.  It looked
> > to me like JOIN_SESSION_KEYRING is the newpag equivalent.
> > Is that wrong?
> 
> No - it depends how widely you want the TGT to be available. I was thinking
> that you might want the TGT to be available to all your sessions by placing i
> t
> in your user keyring.
> 
> > OK, using the new naming suggested by Jeff, here is what I would see
> > (with my UMICH.EDU credentials cache "active" for gssd):
> 
> And the key types?

These would all be "user" keys.

> > This assumes that my default realm is CITI.UMICH.EDU and I've gotten
> > several ticket for the CITI.UMICH.EDU realm.  Then I've done
> > 	% setenv KRB5CCNAME KEYRING:/tmp/krb5cc_20010_umich
> > 	% kinit kwc at UMICH.EDU
> > and then ran the utility to make /tmp/krb5cc_20010_umich my active
> > ccache.  gssd will then try to use my UMICH.EDU tickets to get
> > service tickets to negotiate NFSv4 gss contexts.

After discussing this here with Bruce, I think having more than one
ccache in the session ring is unnecessary.  If you want to do this
sort of thing, you would do the equivalent of a setpag and get into
a new session keyring.  That still leaves the problem of gssd finding
the ccache w/o environment variables.  However, naming the keyring
something like "krb5ccache:<residual>" and having only one ccache
in a session ring would allow it to work.

> 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.  It
then uses that service ticket to negotiate a gss context with the
server and instantiates the gss context key for use by the kernel
client code.  (There is a similar user-land process, svcgssd, on
the NFS server side to negotiate the context with the client.  The
reason for the separate proceseses is historical and has to do with
the different upcall mechanism used by the NFS client and server,
and I probably shouldn't have mentioned it...)


> > >  (5) Users have a key count quota and a key allocation quota.
> > 
> > This is one issue that I am concered with.  I could look at the code...
> > but is the quota configurable?
> 
> 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?