Re: [RFC] change format of LSM hooks

From: Rusty Russell (rustyat_private)
Date: Wed Oct 16 2002 - 18:41:27 PDT

  • Next message: Daniel Phillips: "Re: [RFC] change format of LSM hooks"

    On Tue, 15 Oct 2002 17:07:06 -0700
    Greg KH <gregat_private> wrote:
    
    > On Tue, Oct 15, 2002 at 01:28:28PM -0700, Greg KH wrote:
    > > On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote:
    > > > 
    > > > I will not even look at the networking LSM bits until
    > > > CONFIG_SECURITY=n is available.
    > > 
    > > Good enough reason for me, I'll start working on this.  Help from the
    > > other LSM developers is appreciated :)
    > 
    > Ok, this wasn't that tough...
    > 
    > Here's a first cut at what will need to be changed.  It's a patch
    > against Linus's latest BK tree.  I only converted one hook (the ptrace
    > one), and this will not link, but will build and gives people an idea of
    > where I'm heading.
    > 
    > David, does something like this look acceptable?
    > 
    > With it, and CONFIG_SECURITY=n the size of the security/*.o files are
    > now:
    >    text    data     bss     dec     hex filename
    >     138       0       0     138      8a security/built-in.o
    > 
    > which I hope are a bit more to your liking :)
    > I still need an empty sys_security stub in order to link properly,
    > that's the only function needed.  The extra #includes are needed as
    > some files were getting security.h picked up from shed.h in the past.
    > 
    > I'll work on fixing up the rest of the hooks, and removing the external
    > reference to security_ops, and actually test this thing, later this
    > evening.
    > 
    > thanks,
    > 
    > greg k-h
    > 
    > diff -Naur -X ../dontdiff bleeding_edge-2.5/arch/i386/kernel/ptrace.c lsm-2.5/arch/i386/kernel/ptrace.c
    > --- bleeding_edge-2.5/arch/i386/kernel/ptrace.c	Tue Oct 15 16:47:14 2002
    > +++ lsm-2.5/arch/i386/kernel/ptrace.c	Tue Oct 15 16:41:44 2002
    > @@ -160,8 +160,7 @@
    >  		/* are we already being traced? */
    >  		if (current->ptrace & PT_PTRACED)
    >  			goto out;
    > -		ret = security_ops->ptrace(current->parent, current);
    > -		if (ret)
    > +		if ((ret = security_ptrace(current->parent, current)))
    
    Um, rather than one macro per security_ops function, how about:
    
    #ifdef CONFIG_SECURITY
    	#define security_call(func, default_ret, ...) \
    		(security_ops->func(__VA_ARGS__))
    #else
    	#define security_call(func, default_ret, ...) \
    		(default_ret)
    #endif
    
    This also allows someone in the future to do:
    
    	#define security_call(func, default_ret, ...) \
    		({ if (try_inc_mod_count(security_ops->owner))
    			(security_ops->func(__VA_ARGS__));
    		   else
    			(default_ret);
    		})
    
    Of course, you could skip the default_ret arg, and use
    #ifndef CONFIG_SECURITY
    	#define security_call(func, ...) \
    		(security_default_##func)
    #endif
    
    Then all the defaults can be in a header somewhere.
    
    Cheers,
    Rusty.
    -- 
       there are those who do and those who hang on and you don't see too
       many doers quoting their contemporaries.  -- Larry McVoy
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed Oct 16 2002 - 18:59:23 PDT