Messages in this thread | | | Date | Mon, 4 Jul 2005 12:37:53 -0700 | From | Tony Jones <> | Subject | Re: [patch 5/12] lsm stacking v0.2: actual stacker module |
| |
On Mon, Jul 04, 2005 at 06:51:35AM -0500, serge@hallyn.com wrote:
> > 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...
Are you thinking of resolve_symbol rather than get_symbol?
You are calling __symbol_get("ops").
Maybe (/probably :-)) I'm totally misunderstanding what you are doing but:
a) I would have thought you would need to call symbol_get on the name the caller was passing, i.e symbol_get(capability_security_ops) b) The module registering these ops would need to EXPORT_SYMBOL this name. c) mod->state is MODULE_STATE_COMING right before the call to mod->init in sys_init_module which causes any symbol_gets() to return 0 (not that you actually care about the return value, only it's side effect) d) I don't see anything in this code path that would incr a ref on the registering module as a side effect of returning the sym.
> more stringent locking will be required after all to support unloading. > That, or a rmmod lsm hook.
Yep. I was able to rmmod subdomain and capability, the former with unpleasant results.
Tony - 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/
| |