Re: [patch 5/12] lsm stacking v0.2: actual stacker module

[serge@hallyn.com]

Quoting Tony Jones (tonyj@suse.de):
> 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.

__symbol_get should eventually call try_module_get, which increments the
use count, right?

But I'm completely misusing symbol_get - as you say, that is supposed
to be "symbol_name", not a pointer to the symbol.

Any suggestions on a good way to do what I wanted to do?  Frankly a
new LSM hook seems the cleanest solution.  Or, I could ramp up the
locking and permit module deletion, probably at a bit of performance
cost.  Or I could just count on modules doing a symbol_get on
themselves?

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/