On Tue, 30 Nov 2004 11:00:36 CST, "Serge E. Hallyn" said: > Agreed, we could consider getting rid of mod_reg_security altogether. But > right now I'm just suggesting keeping mod_reg_security, and getting rid of > mod_unreg_security. The module can control how it's loaded, but there's no > point (I can see) controlling how it's unloaded. How many of the existing LSMs permit building as modules, but don't have any code to trap for attempts to rmmod itself? :) We *do* need a "mod_unreg_security()" call that has the semantics of "remove my list of hooks from the appropriate structures". I don't think it has any need to be different for primary/secondary/chained if the code in unreg_security() is able to figure out by itself how the module was registered and undo it. For that matter, are there any existing cases where a module *cares* if it's primary or secondary (as in "returns different results based *only* on its own status as primary/secondary, with *NO* regard as to what the "other" module is"?) I can see where an LSM *might* want to do something like "return A if we also have SELinux loaded, but do B otherwise". For instance, we recently had a discussion about an OpenWall-ish LSM I have, where we decided that most of the function was also doable in SELinux - in a case like that, my code could very well want to defer to SELinux if present, but apply its check otherwise. Testing for if my code is primary or secondary is *wrong* - the fact I'm a secondary is *not* identically equal to selinux running - I *could* be secondary to a LIDS or something else.... That raises a performance question - if a "is FOO loaded" function is provided, can we do it with very low overhead (so it's called each time), or do we need to provide a "FOO is loading/FOO is unloading" notification to other LSM's that might care?
This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 09:57:50 PST