Re: Stacking - anyone care how to report module id's?

dwheelerat_private

Greg KH wrote:

> On Fri, Aug 23, 2002 at 03:42:45PM -0400, David Wheeler wrote:
> 
> But I think you are thinking of a module that manages different security
> modules, right?

Right.

>  If so then your stacking module's call would look
> something like this:
> 
> stacker_sys_security (unsigned int id, unsigned int call, unsigned long *args)
> {
> 	struct list_head *list;
> 	struct stacked_modules *module;
> 	int retval = -ENOSYS;
> 
> 	lock_the_list();
> 	list_for_each(list, &security_module_list) {
> 		module = container_of (list, struct stacked_modules, module);
> 		retval = module->ops->sys_security (id, call, args)
> 		if (retval != -ENOSYS)
> 			goto exit;
> 		}
> 	unlock_the_list();
> 
> exit:
> 	return retval;
> }
> 
> Either way, you don't need to know the ids of the modules.
> 
> Does that help out?

Well, if all the other modules CHECKED the id before
doing anything else, and returned -ENOSYS if it wasn't theirs,
I guess that's okay.
My concern was making sure that I had the "right" return value,
but if everything returns -ENOSYS then presumably that's the
"right" value to return.

It's inefficient, but it won't require any changes to the LSM
interface, and it's only inefficient for sys_security while
stacking, so that's probably okay.

So never mind, that'll work without changing the LSM interface.

BTW, I don't have to lock the list at all in most cases
if I'm going to assume that pointer writes are atomic.
Instead, I'll make removing modules slightly harder.
If you want to remove a stacked module, you'll first have to
"disable" it, and then it's up to the administrator to make sure
that all threads have completed calling the list before
removing the disabled module (and the administrator will have
to decide when it's safe to do so).  Basically, I plan to
trade away safety in module removal in order to gain speed.

--- David A. Wheeler
     dwheelerat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module