All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
	Eric Paris <eparis@parisplace.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] Smack: SMACK_IOCLOADACCESS
Date: Fri, 26 Aug 2011 20:16:30 -0400	[thread overview]
Message-ID: <4E58375E.3010603@redhat.com> (raw)
In-Reply-To: <4E58175A.9090209@schaufler-ca.com>

On 08/26/2011 05:59 PM, Casey Schaufler wrote:
> On 8/26/2011 10:01 AM, Eric Paris wrote:

> Better to have a single question answered as required and with
> complete accuracy than to carry around the baggage necessary to
> maintain a cached duplicate of the kernel's rules and all the
> bookkeeping that requires. SELinux libraries probably have to
> make a system call just to determine if the caches they are
> maintaining are out of date.

Come on Casey, this is Linux.  We have choices!  I believe there are
currently 3 solutions to solving the 'out of date caches' problem.  The
first and oldest is just a syscall per access request option (I think it
does read() but don't remember).  There is an option to get a netlink
message informing you to flush your cache.  SE-XWindows found that ONE
syscall per check was WAY WAY WAY too much overhead and uses this
method.  There is also a magic selinuxfs file which a userspace process
can mmap and just read the memory location to tell if a reload occurred.
 SE-PostgreSQL uses this method because their software architecture did
not have a good way to handle a netlink socket.

The value of the userspace cache is admittedly entirely a question of
the willingness to accept the overhead of kernel lookups.

/me checks out of thread.

-Eric

  reply	other threads:[~2011-08-27  0:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26  5:52 [PATCH] Smack: SMACK_IOCLOADACCESS Jarkko Sakkinen
2011-08-26 12:50 ` Eric Paris
2011-08-26 13:14   ` Alan Cox
2011-08-26 17:36     ` Stephen Smalley
2011-08-26 16:05   ` Sakkinen, Jarkko
2011-08-26 17:01     ` Eric Paris
2011-08-26 21:59       ` Casey Schaufler
2011-08-27  0:16         ` Eric Paris [this message]
2011-08-27  5:57       ` Sakkinen, Jarkko
2011-08-26 16:26   ` Casey Schaufler
2011-08-26 17:28     ` Stephen Smalley
2011-08-26 21:47       ` Casey Schaufler
2011-08-26 17:26 ` Randy Dunlap

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=4E58375E.3010603@redhat.com \
    --to=eparis@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@parisplace.org \
    --cc=jarkko.sakkinen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.