Re: Extending a Security Module

From: Chris Wright (chrisat_private)
Date: Tue May 22 2001 - 13:32:23 PDT

  • Next message: Greg KH: "Re: Extending a Security Module"

    * 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.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue May 22 2001 - 13:37:09 PDT