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

[Tony Jones <tonyj@immunix.com>]

On Mon, Jul 04, 2005 at 03:06:46PM -0500, serge@hallyn.com wrote:

> > 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?

Duh, I missed the call to try_module_get,  probably because it's right
below the 'if (mod && mod->state == MODULE_STATE_COMING) return 0;' :-)
in strong_try_module_get (2.6.13-rc1)

mod->state is MODULE_STATE_COMING until after mod->init returns and since
you are calling __symbol_get indirectly from the modules init routine,
bammo.

> 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?

I think any symbol_get is problematic given the above. I was thinking
you could wrap mod_reg_security but it would still need to be called from
within the modules init fn.

I'm going to have to give it some thought, but a new rmmod hook does seem
a good solution off the top of my head.

Tony