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

[Michael B Allen]

On Tue, 28 Aug 2007 21:03:49 -0700
Howard Chu <hyc@highlandsun.com> wrote:

> Howard Chu wrote:
> > Michael B Allen wrote:
> >> But using a file backed mapping is still no better than a disk file
> >> ccache. You would have to use an anonymous mapping to protect the storage
> >> from non-decendent processes.
> 
> > Anyway, the notion of a kernel driver to solve this problem is definitely 
> > overkill. You can get the same functionality in purely user-level code.
> 
> Of course there's a flaw in both this daemon idea and in Michael's ioctl idea - 
> if a process's parent exits, the child becomes owned by process 1, so you can't 
> rely on walking up the process tree to find a parent ccache. The only sure 
> thing is descriptor inheritance, and that only works if a particular process 
> doesn't stomp on the descriptor before spawning any children.

Hi Howard,

Actually I've changed my mind (somewhat). I think I will pursue the mmap
descriptor inheritance technique. It seems like it could be elegant,
portable and it would satisfy my immediate web server problem and the
implementation interop issue. For some reason I didn't think descriptors
would be inherited across execv but after trying a few tests I am
satisfied that the technique could be quite effective.

However, without a file access point it cannot be used in place of a
regular ccache file. And with it it has the same ownership issue as a
regular ccache file. Also, access control is limited to what inheritance
provides.

Therefore, I still think that the kernel is the only place where a
wide variety of sophisticated access control methods can be implemented
efficiently. Descendant based access control is only one example of the
type of protection someone might want. Locking issues can be handled
much more effectively (e.g. no orphaned semids). The kernel has
the best vantage point to protect sensitive data like credentials.

Mike

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/