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 -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
