Re: Inodes hooks example

gregat_private

On Wed, Apr 18, 2001 at 10:02:45PM -0700, Andrew Morgan wrote:
> 
> These are samples from your patch. First, wouldn't it be more efficient
> to implement this as:
> 
>   SECURITY_HOOK_RETURN_ERROR(retval,basic_ops,ioperm,(),"ioperm
> privilege required");
> 
> [...]
> 
>   SECURITY_HOOK(err,inode_ops,follow_link,(dentry, nd),"attempt to
> follow symlink");
>   if (err)
>       goto loop;

More efficient from a code typing viewpoint, or a memory usage
viewpoint, or a clarity to the programmer viewpoint?

> By abstracting this with a small set of macros, as someone else has
> pointed out, you can then optimize differently on different
> architectures. You can also compile with debugging code on or off (and
> for debugging etc., make use of __FILE__, __FUNCTION__, __LINE__ macro
> definitions by way of small #ifdefs in header code).
> 
> Not to mention it means other folk can leverage your initial work to
> explore different implementations/or even a rival design for the generic
> interface.

Sure, I don't really care at this point in time if these hooks are
implemented as "normal" C code, macros, inline functions, or whatever.
What I'm most concerned right now is:
	- Are the hooks at the right place for everyone?
	  If not, where should they be?
	- Are there enough parameters passed in the hook for everyone?
	  If not, what do people need?
	- For inodes, do people need more hooks?
	  If so, what is needed, and where should it go, with what
	  parameters?

That's what we need to be hashing out right now, not what the calling
syntax of the hook looks like.

But since you brought it up...
Remember that what I implemented allows static tools like the CHECKER to
pass across the module interface to validate rules.  If you make a
generic macro, that expands to a var_args like call, then you lost the
type enforcement, and any static detection tools will never be able to
help you out.

Just my reasoning why I like a simple function call, besides it being the
same type of interface used everywhere else in the kernel source :)

greg k-h
(implementor of unimaginative interfaces)

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

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