On Thu, Sep 06, 2001 at 04:13:30PM -0400, Stephen Smalley wrote: > > On Thu, 6 Sep 2001, Chris Wright wrote: > > > something needs to coallate the modules' decisions and generate an > > aggreagrate result. > > This is true, but the lack of a common header makes a lot more work for > the multiplexor module. As I said earlier, without a common header, > the multiplexor module must save the original security field on entry to > the hook, and then set the field to point to each module's object before > calling each module's hook. Same thing in reverse on allocation of the > objects. The problem is that the modules directly dereference the kernel > object's security field to set and access it, so they are all looking in > the same place. > > If we have a common header, then each module can simply be written to > search the list in the header for its own object, identified by the module > id. Likewise, each module can be written to insert a new blob into the > list when alloc_security is called. This simplifies the multiplexor > module to merely calling the submodules in sequence on the kernel objects, > without needing to tweak the security field at all. That sounds like a nice way to stack your modules together _if_ you want to do that. If not, the overhead of having another void * indirection, and a search on a list of 1 member (another indirection), would not be nice for those people concerned with speed issues. It might be a nice thing to do for round 2 if people think it's worthwhile. I think we should leave it alone for now and polish up what we currently have. thanks, greg k-h _______________________________________________ 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 : Thu Sep 06 2001 - 13:33:27 PDT