On Sat, 29 Jun 2002, Seth Arnold wrote: > Modules should really be recompiled for the kernels they are going to > run on: MODERVERSIONS can sometimes help mitigate problems, but that is > only effective for exported symbols, iirc. So, LSM modules really should > be compiled for specific kernels they will run on. In fact, the modutils > will complain if the versions don't match. ........ > While I suppose this is possib le, it isn't sufficient to think of only > changes to the interface. Changes to underlying kernel code could change > the semantics of some of the hooks, without necessarily changing the > interface. These two seem to be related. If you pass a pointer to a structure in the interface and the underlying structure / function changes, that's below the interface and the module should really KNOW what kernel it's running on. On the other hand, since the LSM interface is going to be in the kernel, it would seem that underlying kernel code changes would have to be tracked or the kernel itself would be broken. Most Significant: kernel version, Lesser Significant: LSM interface version would seem to cover it all, as far as "module think." Any module/integrated-interface solution that works otherwise would probably be "broken", unless you start issuing restrictions on module composition. You can't really "in one big ball" solve every change above and below your interface. You have to "take a stand" somewhere. Perhaps it's just a documentation issue. > > Diligence might be the only answer. > Probably True, Although a CLEVER solution might be interesting, Anxiously Awaiting Discussion and Resolution on This Issue, J. Melvin Jones *------------------------------------------------------- * J. Melvin Jones http://www.jmjones.com/ * Webmaster, System Administrator, Network Administrator * ------------------------------------------------------ _______________________________________________ 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 : Sat Jun 29 2002 - 12:21:33 PDT