Subject: Re: kauth_cred_set* change proposal
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/11/2006 07:20:55
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 11, 2006 at 08:11:10PM +0900, YAMAMOTO Takashi wrote:
> > 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?
My experience with AFS is that we (well, maybe other OSs) currently shove=
the AFS credentials in the kernel.
The problem I see with telling the AFS client to do it all itself is that=
AFS credentials aren't really owned by a UID, they are owned by a process=
or group of processes. The difference is that different groups of=20
processes can be owned by the same UID. Just because one (group of)=20
process(es) gain a credential does not mean that all groups belonging to=20
the same UID should have that new credential.
I just looked on the openafs web page, and I'm talking about a Process=20
Authentication Group above.
Right now, we need only keep a copy of the ID of the PAG we belong to, so=
not much needs to happen w/ kauth.
But the reason we don't need to do much w/ kauth is that we have two=20
different credential systems in use at once, and one of them (kauth) needs=
only hold onto references to the credentials in the other one.
The thing though is that how PAGs work seems realy sensible, and I think=20
it'd be useful to have it be part of the core kernel functionality.=20
If we do add native support for PAGs, then we will need something like=20
what Jonathan was describing; one process, the credential updater, will=20
need to change the credentials for all processes in the same PAG. Thus a=20
process will need to make cred changes that all processes can see.
As an aside, I really like PAGs and would love it if our kerberos used the=
PAG as a ticket store.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----