Solaris ssh pam_krb

[Nicolas Williams]

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
--