lkml.org 
[lkml]   [2005]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-07-04 21:45    [W:0.103 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site