On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote: > On Friday, March 31, 2006 03:44:57 PM -0600 "Douglas E. Engert" > <[EMAIL PROTECTED]> wrote: > >> The caches I see are tiny, > > > > Unless the the KDC is Windows, and the tickets have PACs. A tgt is 2000 > > bytes, but could go as high as 14k. > > Even 14k is still tiny.
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) Sorry, tickets don't belong in the kernel. Even with pageable kernel memory, and proper accounting. Given the choice of complexity in the kernel vs similar complexity in user-land I tend to prefer the latter. I'd like see different arguments one way or the other. See below. > But the issue of ticket storage is tangential to the question of PAG > management. In fact, as far as PAG management is concerned, ccaches are > just another application, whether their contents are kept in the kernel or > in some user-mode daemon or whatever. Yup. > Even if you store tickets and other credentials in user land, there are > still kernel-mode applications like filesystem drivers that need to know > not only what PAG a process is in, but also which PAG's map to the same > application-level identifier. If a user creates a new PAG to break the > association with a single application (say, Kerberos ccaches), then it is > _not_ OK for other applications to be forced to re-fetch cached data. Ok, this is such an argument. I'd like to have some idea of what kernel-land applications actually would need PAG facilities directly, as opposed to indirectly through upcalling to daemons like gssd. NFS clients don't need direct PAG access -- see gssd. NFS servers don't either -- same thing. Both need to track process/client cred_t's and file "open owners" (to borrow a term from NFSv4). But that's what cred_t is for. What about CIFS clients and servers? AFS? How are they fundamentally different from NFS in this respect? What about KINK? Would you implement KINK in the kernel? Or in user-land? IKE in Solaris is implemented in user-land, why should KINK not be implemented in the same fashion? What about kernel-land TLS (RFC2712? Ick) accelerators, do they need direct PAG access, or can they afford to upcall to resolve the location of relevant certs/private keys/tokens? What other kernel-land applications can you think of or imagine that fundamentally needs direct multi-application PAG support in the kernel and can't upcall? Nico -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
