Re: removal of the version field from struct security_operations

From: Valdis.Kletnieksat_private
Date: Tue Oct 30 2001 - 10:15:41 PST

  • Next message: Greg KH: "Re: removal of the version field from struct security_operations"

    On Tue, 30 Oct 2001 12:46:32 EST, Stephen Smalley said:
    > Well, the version field would catch an attempt to load a security module
    > built against a different version of the LSM security.h file.  I don't
    > know if that is worthwhile, since people should always compile their
    > modules against the appropriate kernel headers.  No real objection here.
    
    I remember thinking "what does this do for us?" as well... but then
    I did a bit more research, and found this in Documentation/Configure.help:
    
    Set version information on all symbols for modules
    CONFIG_MODVERSIONS
      Usually, modules have to be recompiled whenever you switch to a new
      kernel. Saying Y here makes it possible, and safe, to use the
      same modules even after compiling a new kernel; this requires the
      program modprobe. All the software needed for module support is in
      the modutils package (check the file Documentation/Changes for
      location and latest version). NOTE: if you say Y here but don't
      have the program genksyms (which is also contained in the above
      mentioned modutils package), then the building of your kernel will
      fail. If you are going to use modules that are generated from
      non-kernel sources, you would benefit from this option. Otherwise
      it's not that important. So, N ought to be a safe bet.
    
    
    So it looks like if you say 'N' here, the work's already done for us.
    Unfortunately, there's that "non-kernel sources" that we *already*
    had a nice flame-fest about (with GNU licenses and all that).
    
    /Valdis
    
    _______________________________________________
    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 Oct 30 2001 - 10:16:39 PST