Re: [RFC] change format of LSM hooks

From: Rusty Russell (rusty@rustcorp.com.au)
Date: Wed Oct 16 2002 - 20:41:27 EST


On Tue, 15 Oct 2002 17:07:06 -0700
Greg KH <greg@kroah.com> 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
-
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/



This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:31 EST