In message <1151879584.916316.815.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:

>> unless anyone objects, i'll make kauth_cred_set*() return
>> a new credential and remove kauth_cred_copy.
>
>a person asked me privately why i want to make this change.
>i thought it was obvious, but anyway, here's an answer.
>
>- in this way, a caller doesn't have to worry if kauth_cred_copy is
>  necessary or not.  it's easier to use, at least for me.
>
>- afaik, there's no demand to modify a shared credential and let
>  others see the modification.

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.
 
[...]