On Friday, March 31, 2006 03:44:57 PM -0600 "Douglas E. Engert" <[EMAIL PROTECTED]> wrote:
> > > Ken Hornstein wrote: > >>> Why store tickets in the kernel, what's the point? Presumably you'd not >>> want anything other than TGTs in the kernel, so where do you cache >>> service tickets? Or do you want all tickets in the kernel? (Presumably >>> in pageable, accounted memory...). >> >> >> Well, actually, I'd rather have the whole ticket cache in the kernel. >> I have personally seen attacks on the current file cache; right now we >> don't use a file cache, but the scheme we do use has some issues. One >> thing we were planning on doing was use the Linux kernel keyrings >> if/when they become suitable ... but of course those would only work >> under Linux. I know that putting the ticket cache in the kernel isn't >> 100% protection, but I think it's the best we can probably do on a >> multi-user Unix system. 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. Charge the space against the user, or the PAG, like Linux keyrings do. In fact, now that I think about it, a similar approach can be used for kernel PAG->appid mappings. Simply impose a limit on the number of such mappings which can be associated with any given PAG. Each mapping is nothing more than an application type and application ID, both of which are integers. You need an mapping between application type names and their ID's, but _that_ can be managed in user space. And if you find you need more apps per PAG, then change the system parameter - it doesn't even have to require a reboot, depending on how you allocate the storage. 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. 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. -- Jeff ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
