On 18 Aug 2001, David Wagner wrote: > Seth Arnold wrote: > >I was initially concerned that it was magic looking until I actually > >lookd at the modified functions.. but I wonder how folks would prefer > >one hook multiplexed by an int, or two hooks, one for each? > > One disadvantage of multiplexing hooks is that it gets slightly harder > to reason about policy when you do so (grep stops working as well). > Also, I'd expect that hook bodies will start looking slightly more > complex (switch statements and so on). For these software engineering > reasons, it seems that having two hooks might make more sense. What do > you think? > Just a brief thought: the reboot hook takes cmd, which is basicly a multiplexer entry that is used in sys_reboot. How is this relevant? Beats me, except nobody has considered splitting it into multiple hooks, yet. And nobody has ever considered an "lsm_function(int selector,...)" call, yet, outside of a module. The multiplexing work has been done by the placement of the hooks in the kernel. If this call is never likely to get a value other than 0 or 1, then two hooks seems both doable and consistant. The cost of multiplexing that one bit, in this case, seems to outweigh the clutter of two hooks. Is there any forward looking reason (like somebody who knows there will be a few other values added in the future) not to split it into two hooks? We seem to have a pattern of separating "on" and "off" hooks, thus far, in the interface. I'd suggest this should be continued here... and that an integer multiplexer is only appropriate if there are more than two options. On the other hand, if there're more values for that argument that we rationally MAY wish to capture in the future (or optionally, by module), I'd like to keep that option in the hook. Hooks are cheap, switch'd and if's cost a little, Minor Issue, Comming Down Lightly On Both Sides Of The Fence, J. Melvin Jones P.S. -- Soooooo quiet, this list, this weekend. I hope everybody is having a better RL weekend than me, and that it's not a technical artifact. ;) |>------------------------------------------------------ || 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 : Sun Aug 19 2001 - 13:07:11 PDT