On Tue, 28 Aug 2007 21:03:49 -0700 Howard Chu <[EMAIL PROTECTED]> 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/ _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
