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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 04, 2005 at 06:51:35AM -0500, [email protected] 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux