Re: [OpenAFS-devel] Re: MEMORY credential cache interop between Heimdal and MIT?

[Troy Benjegerdes <hozer@hozed.org>]

On Thu, Aug 30, 2007 at 09:59:07PM -0400, Michael B Allen wrote:
> On Thu, 30 Aug 2007 21:42:39 -0400
> Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> 
> > Just so we're clear: I think a kernel solution is preferrable.  But I
> > was given the task to solve the problems associated with Kerberos tickets
> > on disk NOW, dammit, so cajoling various vendors into developing a solution
> > and waiting the couple of years it would have taken to get that into
> > their products was simply not an option.
> 
> You don't have to wait. Any OS worth it's weight in bits has loadable
> kernel modules. You create a source package that is compiled against
> some kernel headers to get a module that can be loaded directly into the
> kernel (as root of course). Vendors can provide binaries for each kernel
> package so that auto-updates work smoothly. VMWare does this. They have
> kernel modules that are constructed and installed on-the-fly.

I completely agree. What OS are we waiting for? Linux has a kernel
keyring, OSX has some form of in-memory caches, and windows has
kerberos as part of active directory.

I might also add that if we are talking about kernel modules, it's
probably also worth thinking about hypervisor keyring modules as well.
All of these schemes fall down when you are running a VM in a hypervisor
and then checkpoint the VM to disk. If the guest kernel can pass all the
tokens up to the hypervisor, the hypervisor can intelligently decide
what to do, and might even provide some very nice user interface
integration.. if you renew your tickets on the host OS, appropriate 
tickets get propagated to all the VM's you are running that have kernel
keyring modules loaded that can talk to the hypervisor.