Messages in this thread | | | Date | Mon, 4 Jul 2005 06:51:35 -0500 | From | serge@hallyn ... | Subject | Re: [patch 5/12] lsm stacking v0.2: actual stacker module |
| |
Quoting Tony Jones (tonyj@suse.de): > Hey Serge, > > I don't think your symbol_get() is doing what you think it is ;-)
Hmm, I wonder whether something changed. It shouldn't be possible to rmmod module b if module a has done a symbol_get on it... This may mean more stringent locking will be required after all to support unloading. That, or a rmmod lsm hook.
> > + * Add the stacked module (as specified by name and ops). > > + * If the module is not compiled in, the symbol_get at the end will > > + * prevent the the module from being unloaded. > > +*/ > > +static int stacker_register (const char *name, struct security_operations *ops) > > +{ > ... > > + symbol_get(ops); > > + > > +out: > > + spin_unlock(&stacker_lock); > > + return ret; > > +} > > > Seemed useful to be able to view which modules had been unloaded. > Easier to maintain them on their own list than to compute the difference > of <stacked_modules> and <all_modules>. Patch attached, not sure if you > are cool with reusing the 'unload' file.
No, that's good, thanks. Though I guess "unloading" of this type won't be needed if true module deletion has to be supported.
> Apart from this, looks good. I ran it against our regression tests using > AppArmor (SubDomain) composed with Capability and everything was functionally > as expected. I still need to run it through our SMP stress tests.
Excellent :)
thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |