[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OpenAFS-devel] Re: MEMORY credential cache interop between Heimdal and MIT?
>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
- 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.