* Ashwin Ganti <[EMAIL PROTECTED]> wrote: > 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/
Great, I'll have a look at it :) > > 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 integeruser ids. This > daemon would be contacted by the kernel to resolve the user names > it gets after parsing the capabilities written to the device > (by theprocess and the hostowner's factotum)". Yeah, I already though about this way before. But I actually don't like this approach (kernel calling userland) not very much. There are too many ways to things get wrong (deadlocks, etc). Another approach could be pushing the uid<->name table through an special file. This would be much simpler/stable, but then we'll loose the the ability for fully dynamic/external account management (eg. NIS or DB-driven), and on systems w/ many accounts we'll waste a lot of memory :( Nevertheless we'll need an userland daemon at some point. So I chose to keep the kernel change as small as possible (my patch is quite small - most of it are some generic helpers) and also quite universal (can also be used for a lot of other things like debugging). My plan is to serve the cap* devices entirely from userland (via sockets). > I think NFS solves this in a similar way? That's very different. NFS itself doesn't know of usernames, just UIDs. But it has an mapping service, which looks up the username for some given UID and ask the remote side which UID this name corresponds there (actual mapping is uid->uid). This thing is quite unstable, and I don't like to go this way again. > For the port I worked around by adding usernames as string > equivalents of uids (like "1001") which is ugly but can be For that to work, the server has to understand this. I have my doubts that native Plan9 will do ;-o > > 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) Well, on Linux, you'll also have to trust some parts of the userland, at least things like modprobe ;-P Of course this should be minimized, but in solutions there will be an userland daemon which must be trusted. You mapping service could be abused quite the same as my cap service. I don't see any way out of this, as long as the kernel isn't aware of usernames completely by itself (and this would require a major break w/ Unix philospophy). 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/ ---------------------------------------------------------------------
