Titus D. Winters wrote:
>> > 2. Maintain current set of hooks and push logic out of the kernel and into
>> > the module to avoid placing hooks in compound conditionals.
>
>Yes, this is certainly an invasive solution, but not only is it the most
>general, it is the most elegant as well.
Elegant? Not from a software engineering point of view.
Almost every module will have a cut-and-pasted copy of the base
logic. Software engineering teaches us that code duplication is
bad: If you ever want to change that code, making the appropriate
change in all necessary places is difficult.
>> > 3. Maintain current set of hooks and keep logic in the kernel. Add an
>> > argument to hooks to show whether the kernel was going allow or deny the
>> > action.
>
>I think, as a gut reaction, that this is going to make the hook checks in
>the base kernel a lot ugly and more incomprehensible.
I don't think so.
if (err = security_ops->hook(x, y, z))
goto out;
becomes
if (err = security_ops->hook(err, x, y, z))
goto out;
I don't see why you consider the latter ugly and incomprehensible.
It's not elegant, but it doesn't seem ugly, either, and it seems pretty
easy to understand what it's doing. What am I missing?
-- David
_______________________________________________
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 - 11:13:26 PDT