On Wed, 6 Jun 2001, Stephen Smalley wrote: > > > That's true, as far as it goes, but it prohibits anybody from wanting > > that from using it, and forces any who DON'T, to accept it. > > I don't follow your argument. Let's say that my module only wants > to implement restrictive behavior on permission(). So, > the module's permission hook function might look like: > <snip> I concede that your example will allow either permissive or restrictive, and is very compact. My objection is that, in any case, your solution requires the kernel logic to be evaluated before the module is called, and requires a hook by hook decision as to if it may be relevant enough to include the argument in the list. This creates the following situation: 1) Module designs that totally ignore the original kernel logic must still wait for it to be resolved, discarding the result. 2) A consensus must be reached in the design of the interface to add "kern_retval" to each hook that "may" need it. While we're all one big happy family ;), I suspect that different security module designs will need it in different places. Requiring a central decision on where to add it instead of a mechanism that allows individual modules to "choose" if kern_retval is significant, (and, therefore, if it needs be calculated,) not only puts us in a perpetual argument for "add this", but forces those that don't need it to pay (the computational cost) for it. 3) If you move the kern_retval check to AFTER the module, by the request of the module, it is possible that some of what is checked (such as euid) *may* be altered by the module before the evaluation is done, allowing the module some influence in the result. Yes, you could duplicate the check in the module with a value changed, but now you're doing the check twice. I think your solution is very viable, I only disagree with a few of the minor "implications" thereof. I am wondering if a slightly less compact solution might not be worth the "muss" for the added flexability. J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Wed Jun 06 2001 - 06:17:31 PDT