>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! >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. 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. --Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos