On Fri, Mar 31, 2006 at 05:38:30PM -0500, Ken Hornstein wrote: > >If you're using Kerberos V for authentication in remote administration > >protocols and have, say, 30,000 hosts to look after then your ccache > >would grow to: > > > >14KB x 30,000 = *huge* (~410MB) > > Oh, come on ... this is a strawman argument. You'd have to make some > serious changes to make this work with what we have today! Even with a > disk file!
I know, but *I* needed this once. > >Sorry, tickets don't belong in the kernel. Even with pageable kernel > >memory, and proper accounting. > > It seems like it would make sense to let the user/administrator make that > choice, instead of focusing on a hypothetical worst case. Sure, it > might be really bad for a few sites ... so they have to use something > else. But why deny the choice for other sites? > > >Given the choice of complexity in the kernel vs similar complexity in > >user-land I tend to prefer the latter. > > I can't think of any kernel-land application that can't live with an > upcall to user-space interface, like gssd does today. The only thing > that concerns me is how is gssd going to access credentials in someone > else's PAG? And if gssd can do it, then what prevents other user-land > applications that are not part of the user's PAG from doing the same > thing? The one thing I really like about the current implementation of > AFS PAGs today is that root can't get at anyone else's AFS tokens > without diving into the kernel. GSSD, today, is a privileged application. In the future we may have per-user or per-PAG GSSD instances, with the primary GSSD serving only as a registration service for the former. > Now, I'd be happy with something that we could hypothetically call > "nfslog" that would talk to gssd or the kernel directly and run in the > user's PAG to get tickets. Well, I guess "happy" wouldn't be the right > word ... I'd be _satisfied_ with it. I'll take your being satisfied :) Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
