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

[Ken Hornstein <kenh@cmf.nrl.navy.mil>]

>Again, I don't understand _why_ a kernel solution is preferable.  Why
>tart up the kernel with a bunch of junk code (which from my point of
>view is _precisely_ what the "magic groups" PAG implementation does)
>when the inheritance semantics of MAP_ANON mmap mappings are already
>exactly what you want?

A couple of reasons from my point of view.  None of them are exactly very
strong:

- I don't see how to do locking of the mmap()'d region in a reasonable
  manner.  My issue with Sys V semaphores is that they don't clean themselves
  up.  I could use a shared descriptor to coordinate access ... but that
  gets back to all of the other problems with shared descriptors.  I imagine
  you could come up with some scheme, but I think it would be a bit hinky
  and not cover all of the corner cases.

- There is from what I see not a wonderful way to share that memory location
  to decendant processes.  I guess putting the memory address in an environment
  variable is probably no worse that what is done today (I guess you'd
  have a KRB5CCNAME variable that looks like "MMAP:0x12345678").

- It seems like all of these schemes were originally designed for processes
  that were tightly coupled; they weren't designed to work across a login
  session.  They work, but they feel ... fragile, somehow.

I'm not saying the entire set of credentials has to be placed in the
kernel.  MacOS X has a reasonable scheme; the kernel provides a
mechanism that has the right inheritance semantics (Mach RPCs) and you
communicate with a userland process to get your credentials.

Anyway, Thor, you could easily prove me wrong and simply WRITE the mmap()
credential cache yourself.

--Ken