Solaris ssh pam_krb
Nicolas Williams
Nicolas.Williams at sun.com
Mon Apr 3 15:35:07 EDT 2006
On Sat, Apr 01, 2006 at 12:13:31AM -0500, Ken Hornstein wrote:
> >Ken is wrong.
>
> Careful, now :-) When I was agreeing with Nico, I was specifically
> talking about storing Kerberos tickets in the kernel versus something
> in userspace. I think that there is no technical reason you cannot
> have a userspace daemon hold/manage those tickets, _much like is done
> with gssd today_ (I know that gssd doesn't hold Kerberos tickets, but
> let's pretend that it does). Mind you, I still would prefer that they
> be stored entirely in the kernel. However, that is of course EXTREMELY
> distinct from what PAGs get you. A userspace upcall to fetch a Kerberos
> ticket that is associated with a PAG would happen relatively infrequently,
> and I don't think would affect performance that much. But if you had
> to do an upcall to deterine PAG membership, that _would_ be a problem;
> that's why I ultimately decided that the MacOS X security context stuff
> wasn't usable for AFS. I'm definately in Jeff's camp on this point.
> I'm sorry if my earlier email was unclear on this subject.
PAG membership would have to be a kernel-side thing; throwing multi-app
PAG associations into the mixture simply means that kernel applications
that need to track such associations would either have to upcall or find
a way to track them kernel-side, and this might turn out to be onerous.
But so far I've seen not one example of a kernel application that should
care about PAGs _directly_, assuming that PAGs are not a session
separation feature (which Jeff seems to conceded from time to time :)
Nico
--
More information about the Kerberos
mailing list