Subject: Re: kauth_cred_set* change proposal
To: None <jonathan@cs.stanford.edu>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 07/11/2006 20:11:10
> Yamamoto-san,
> 
> I'm impaired, so I apologize in advance if this a stupid question, but:
> 
> Did you consider reomte-file-access protocols with stashed-in-kernel,
> per-login session, limited-lifetime credentials?  AFS is one example,
> where credentials are per-session, and refreshing of client creds
> should definitely be shared across an entire login session.
> 
> The usage model here is that when your AFS tickets expire (or are
> close to expiriing), you get fresh tickets; and the fresh tickets are
> injected into the kernel, where kauth_cred_set() is expected to update
> one shared cred object, containing krb tokens, for the whole session.
> 
> I don't recall enough about NFSv4 (or NFSV3 with RPSEC_GSS krb5 creds)
> but I suspect the same issue arises there.  (I'd check check Rick
> Macklem's implementation, if only I could recall where I put my copy).
> 
> I'm absoutely certain AFS and OpenAFS behave as I describe. When your
> tickets expire, you typically can't access files; when you refresh the
> tickets, all proceses (subshells, editors, ...) in the login session
> can access files again. (I think Solaris NFS-with-RPSEC_GSS behaves
> that way too, but I may well be misremembering ancient AFS...)
> 
> If similar behaviour is desirable for NFS-with-RPCSEC_GSS, it would be
> a shame to preclude it.
>  
> [...]

do you mean to put AFS remote (on-wire or server-side or whatever)
credential into kauth_cred_t?
isn't it a matter of mapping between local and remote credentials,
which should be handled by AFS client, not kauth?

(sorry, i have no idea how AFS works.)

YAMAMOTO Takashi