mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kurt Garloff <garloff@suse.de>
To: Linux kernel list <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@osdl.org>
Cc: Stephen Smalley <sds@epoch.ncsc.mil>,
	James Morris <jmorris@redhat.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Steve Beattie <smb@wirex.com>
Subject: [PATCH 0/3] LSM hooks consolidation
Date: Sun, 3 Jul 2005 17:43:11 +0200	[thread overview]
Message-ID: <20050703154311.GA11093@tpkurt.garloff.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi,

here is the version of my patches that rework the security 
stubs in security.h a bit to allow for better maintainability
and allow the possibility of using conditionals over indirect
calls. The latter has been found beneficial with tcp_rr benchmarks
on ia64.

To stress the maintainability point: One of the void stubs had a
return statement in there, which was inconsistent between the
cap_ and security_ops-> versions.

The first patch, as a prerequisiste, makes capabilities the default
for CONFIG_SECURITY=y rather than the dumb dummy, which results in
a broken system -- which makes everybody wanting to load capability.
Not the idea, as this makes loading other LSMs problematic ...

Note that I did not drop dummy completely. I think it should ... but
currently LSMs that don't have all functions implement fall back to
the implementations in dummy. I did not want to change behaviour and
fall back to the ones in capability. Most are identical between cap
and dummy, but I did not review all existing LSMs. It could be done
at a second step if deemed viable.

Note that the patches have been discussed before:
http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/1040.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/0623.html

In comparison to the last submission, I have dropped the unlikely() 
stuff that seemed too controversial. 
The patch 2 which does the main cleanup has been split in two.
The first is produced by a little python script that parses the
function implementations and the ifdefs and reorders them, so
they end up next to each other. This greatly simplifies the creation
of the next patch and minimizes the chances to screw up.
I marked these patches 2a and 2b.

Please apply!
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2005-07-03 15:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-03 15:43 Kurt Garloff [this message]
2005-07-03 16:49 ` James Morris

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=20050703154311.GA11093@tpkurt.garloff.de \
    --to=garloff@suse.de \
    --cc=chrisw@osdl.org \
    --cc=gregkh@suse.de \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@epoch.ncsc.mil \
    --cc=smb@wirex.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

all inboxes | Powered by JetHome®