ccache using linux Keyrings

[Frank Cusack]

On April 19, 2006 12:35:40 AM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
>>
>> I've been trying to educate myself on this, but I can't find *any*
>> documentation whatsoever for the keyring (sigh).  Anyone have any pointers?
>
> I have the same problem.

Daniel was approximately correct; it's Documentation/keys.txt in the linux
source tree.

Having glanced at it, it seems like a good place to store krb5 creds.  I
have a question.

Currently, if an nfs service ticket expires, gssd tries to obtain a new
one using a (hopefully) available TGT.  If a process acquired a new session
specific nfs cred (ie, stored a cred in a new session keyring for nfs to
find), how should gssd renew this ticket?  The session specific ticket may
be for a different principal than the TGT available to gssd.  Consider:

  sudo ls
    - sudo creates a new session keyring (via PAM)
    - user creds go into session keyring
    - root user can access user's files
    - ticket expires
    - gssd upcall for user root, which is the wrong user

1) note that this doesn't work today -- sudo ls uses root creds not user creds,
   but the behavior above is something I'd like
2) it isn't clear to me if root can read user's keys/keyrings, if so than
   sudo doesn't need to create a new session keyring
3) this might argue for tgt in the keyring -- not to be used by the kernel
   itself but just as storage so (eg) upcall to gssd can pass the correct tgt

Maybe this kind of thing has already been discussed in this thread or AFS
threads elsewhere.  Sorry to come in late and uninformed.

-frank