From: Rusty Russell <rusty@rustcorp.com.au>
To: Greg KH <greg@kroah.com>
Cc: davem@redhat.com, becker@scyld.com, jmorris@intercode.com.au,
kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com,
linux-security-module@wirex.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] change format of LSM hooks
Date: Thu, 17 Oct 2002 11:41:27 +1000 [thread overview]
Message-ID: <20021017114127.759e0e81.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20021016000706.GI16966@kroah.com>
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
next prev parent reply other threads:[~2002-10-17 1:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-15 14:36 [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) James Morris
2002-10-15 17:40 ` David S. Miller
2002-10-15 18:14 ` Donald Becker
2002-10-15 19:16 ` Greg KH
2002-10-15 19:34 ` David S. Miller
2002-10-15 19:45 ` Greg KH
2002-10-15 19:45 ` David S. Miller
2002-10-15 20:12 ` Greg KH
2002-10-15 20:10 ` David S. Miller
2002-10-15 20:28 ` Greg KH
2002-10-15 20:24 ` David S. Miller
2002-10-16 0:07 ` [RFC] change format of LSM hooks Greg KH
2002-10-16 0:03 ` David S. Miller
2002-10-16 8:15 ` Greg KH
2002-10-16 18:59 ` Greg KH
2002-10-16 19:07 ` Greg KH
2002-10-17 1:41 ` Rusty Russell [this message]
2002-10-17 3:33 ` Daniel Phillips
2002-10-17 13:21 ` Christoph Hellwig
2002-10-17 16:55 ` Greg KH
2002-10-19 2:33 ` [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Keith Owens
2002-10-19 2:54 ` Keith Owens
2002-10-19 3:29 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021017114127.759e0e81.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=becker@scyld.com \
--cc=davem@redhat.com \
--cc=greg@kroah.com \
--cc=jmorris@intercode.com.au \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@wirex.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).