On Fri, Jun 01, 2001 at 12:39:57PM -0400, jmjonesat_private wrote: > That, and, the only "clean" way I can feel happy about #3 is to leave > the capabilities in the kernel altogether and it might be easier to > sell the whole package if we listen to "Linus specifically said that > he would like to see the capabilities mechanism moved out of the > kernel into a module." I don't think we can say that quite so specifically. :) http://mail.wirex.com/pipermail/linux-security-module/2001-April/000005.html The closest I found in either of those two emails is something along the lines of, "pluggable good, capabilities nice default". I never got the impression that Linus would accept our work only if capabilities is moved to module space. Now, for my votes: I don't like the many possible hook placement idea. The one that moves a lot of logic into modules sounds workable and is perhaps my preference. The one that passes the kernel's suggestion along is actually my favorite *where the kernel makes any sort of decision already*. I haven't looked at the hook placements carefully enough to know if the kernel always makes decisions near hooks or not, but I can easily imagine it not bothering. And I wouldn't much like to pass dummy values around, nor would I like to clutter the interface so that some hooks accept arguments and other hooks do not -- based on their current placements in the kernel. Yeah, option number two sounds fine to me, though I am not enamoured with it. (Primarily because each module author will either need to duplicate the functionality of the current kernel checks, or will need to chain modules together. Worse things have happened, though. :) Cheers _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jun 01 2001 - 10:04:30 PDT