* jmjonesat_private (jmjonesat_private) wrote: > > Unless I'm missing something, > > create security_ops->register() > create security_ops->unregister() > > If register_security() detects an existing module registration, > instead of failure, pass the new ops pointer to the > security_ops->register() function. > > If the module can't provide "chaining" or replacement functions, > it could just fail, if it CAN, it returns success and can worry > itself if it calls the new hook before or after or never, > and possibly unregister and register a new structure since it > holds "the magic address". This would work for your needs (the lsmexample plus capability_plug). I'm not sure it would solve the general problem. First issue...what is the composite meaning of a hook. Your proprosal does turn this in to a policy decision for each module writer (do you let later modules override your decisions or not). Do you trust a random module registering with you? Second, what do you do when you _both_ want to access the security blob? Copying things in and out of the security blob isn't too nice, nor is ugly casting with special purpose structs. I don't think we can go this route. -chris _______________________________________________ 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 : Tue May 22 2001 - 13:37:09 PDT