On Tue, May 6, 2008 at 1:22 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > http://plan9.bell-labs.com/iwp9/papers/13.p9auth.pdf > > cool, I wasn't aware of this. never ever seen a patch for > the cap devices. does anyone have link ?
The device driver is in: http://gsoc.cat-v.org/hg/lincapdevice/ The authentication server port is in: http://gsoc.cat-v.org/hg/p9pauthsrv/ Although I still have to work on some feedback from Russ to get it polished so that it can be made part of p9p. > > My decision for the *uid files (instead of cap devices) was > because: > > a) more flexibilty (not only limited to factotum stuff) > b) the kernel doesn't know of usernames. That is one of the future improvements that I had listed in the paper. "It would also be nice to have a user space mapping daemon that maps the string user names and the integer user ids. This daemon would be contacted by the kernel to resolve the user names it gets after parsing the capabilities written to the device files (by the process and the host owner's factotum)". I think NFS solves this in a similar way? For the port I worked around by adding usernames as string equivalents of uids (like "1001") which is ugly but can be avoided with this daemon. Check out the paper for details. > > So, IMHO, the cap handling should be done in userland. Well, I feel it is more secure to have the kernel manage the capabilities and do the actual identity change. We trust the kernel (it is part of the TCB) > > > > > cu > -- > --------------------------------------------------------------------- > Enrico Weigelt == metux IT service - http://www.metux.de/ > --------------------------------------------------------------------- > Please visit the OpenSource QM Taskforce: > http://wiki.metux.de/public/OpenSource_QM_Taskforce > Patches / Fixes for a lot dozens of packages in dozens of versions: > http://patches.metux.de/ > --------------------------------------------------------------------- > >
