--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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...)
> >=20
> > If similar behaviour is desirable for NFS-with-RPCSEC_GSS, it would be
> > a shame to preclude it.
>=20
> 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=
=20
the AFS credentials in the kernel.

The problem I see with telling the AFS client to do it all itself is that=
=20
AFS credentials aren't really owned by a UID, they are owned by a process=
=20
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=
=20
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=
=20
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=
=20
PAG as a ticket store.

Take care,

Bill

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEs7PHWz+3JHUci9cRAo0OAJ0ev3nL0XzyVcwYMoi7a55Bb8xvTQCeJJHx
akC0znsW1S2rmn+pZeSu7Ro=
=7+NX
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--