On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote: >> On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams >> <[EMAIL PROTECTED]> wrote: >> > 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? >> >> - Encrypted (local) filesystems > > Orthogonal to PAGs. The kernel needs to know keys for encrypting > objects/filesystems, but access controls are as normal (ACLs, mode bits). > > We're planning on per-filesystem (think ZFS) keys, too, so there's no > per-"session" keys to worry about. I was thinking in terms of different users' files being encrypted with different keys, which would require the kernel to track keys on approximately a per-PAG basis. >> - Kernel-mode ticket caches > > Circular logic. No, it's not. We already established that ticket caches are separate from PAG management. If you want kernel-mode ticket caches (and some of us do), then you need kernel-mode access to PAG->appid mappings. >> Maybe PAG-based authorization for things like X server or ssh agent >> connections. In reality, I bet those can be handled in user mode, >> though an application like that would require some trusted entity for >> allocating ID's which are unique across the system. > > Authorization by PAG requires making changes to lots of things in the > kernel (e.g., two procs w/ equal cred_t's but for different PAGs should > not be allowed to trace each other w/o special privilege). Well, yes, and in the long run, you'd want that even if there were no kernel-mode users of PAG's. But I considered the filesystem-driver applications critical. An upcall for every file access is just not going to be acceptable performance-wise. Really, I think the introduction of a new process to keep track of PAG->appid mappings is just silly. The number of PAG application types in the system is likely to be quite small, and the mappings themselves are small as well. Why not just store them in the PAG structure and be done with it? -- Jeff ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos