I've now released an update to "stacker.c", dated 2002-07-22. It's at: http://www.dwheeler.com/misc/stacker.c The big change is that it now has a locking system, and it uses rw_semaphor in a VERY conservative way to do so (as promised). _Any_ hook call grabs the lock first - most of them grab the lock for reading (allowing many multiple uses), but a few operations grab the lock for writing. This approach drains some performance, but it's easier to ensure that it's correct this way. The implementation of sys_security now only calls the module with the matching id, so the return value is replied. Unfortunately, the LSM hook interface doesn't provide the id, and currently stacker assumes that all IDs are 0. In other words, currently sys_security is broken. Rather than kludge a solution, I'm hoping that people will agree to add the id information to either the mod_reg_security parameters or to the security_ops passed to mod_reg_security. That will eliminate the problem in a more graceful way. Can I convince anyone to do either? P.S., If it's added to security_ops, its default value needs to be non-zero so the VERIFY macro won't accidentally cause problems. Do _not_ try to run stacker yet. Comments welcome! _______________________________________________ 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 : Mon Jul 22 2002 - 22:49:31 PDT