Right, sorry, I just meant not being able to modprobe the module hours or days after boot. Really, I guess even with the case of bsdjail, you could insert the module anytime, since it only creates jails on new processes. On the other hand, whereas it currently only creates a jail when a process does an exec under certain conditions, it now would have to create an empty jail for each newly created process. I also see a problem with module unloading, since an LSM can't just run through and delete all it's data. Just using kref structs doesn't even help since the free hook would have to remain loaded. -serge On Tue, 2005-02-01 at 08:48 -0500, Stephen Smalley wrote: > On Tue, 2005-02-01 at 08:30, Crispin Cowan wrote: > > Serge E. Hallyn wrote: > > > > >I hadn't considered that. It does seem to then enforce that any > > >security module keeping state on kernel objects must be compiled in > > >so as to catch them when they are created. But that may not be a > > >bad thing, and it would be nice to be able to drop the rwlock. > > > > > > > > Forcing a stackable module to be compiled in would seem to be a fatal > > flaw. The whole point of stacking is to be able to compose things that > > your upstream provider did not think of. > > I'm not sure that it would truly require making the module builtin, just > inserting any loadable module early during system initialization before > other processes are running. But that is good practice anyway. > -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 06:22:16 PST