From: James Morris <jmorris@namei.org>
To: David Howells <dhowells@redhat.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, nfsv4@linux-nfs.org,
steved@redhat.com, linux-fsdevel@vger.kernel.org,
torvalds@osdl.org, linux-cachefs@redhat.com,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 11/14] CacheFiles: Permit an inode's security ID to be obtained [try #2]
Date: Thu, 9 Aug 2007 12:34:13 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0708091223330.19611@us.intercode.com.au> (raw)
In-Reply-To: <22259.1186686459@redhat.com>
On Thu, 9 Aug 2007, David Howells wrote:
> James Morris <jmorris@namei.org> wrote:
>
> > David, I've looked at the code and can't see that you need to access the
> > label itself outside the LSM. Could you instead simply pass the inode
> > pointer around?
>
> It's not quite that simple. I need to impose *two* security labels in
> cachefiles_begin_secure() when I'm about to act on behalf of a process that's
> tried to access a netfs file:
Ah ok, we had a similar problem with NFS mount options.
While I'm concerned about encoding SELinux-optimized secid labels into
general kernel structures, moving to more generalized pointers introduces
lifecycle maintenance issues and complexity which is not needed in the
mainline kernel. i.e. it'll be unused infrastructure maintained by
upstream, and used only by out-of-tree modules.
So, given that the kernel has no stable API, I suggest accepting the u32
secid as you propose, and if someone wants to merge a module which also
uses these hooks, but is entirely unable to use u32 labels, then they can
also justify making the interface more generalized and provide the code
for it.
- James
--
James Morris
<jmorris@namei.org>
next prev parent reply other threads:[~2007-08-09 19:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 16:04 [PATCH 00/14] Permit filesystem local caching [try #2] David Howells
2007-08-09 16:04 ` [PATCH 01/14] FS-Cache: Release page->private after failed readahead " David Howells
2007-08-09 16:04 ` [PATCH 02/14] FS-Cache: Recruit a couple of page flags for cache management " David Howells
2007-08-09 16:04 ` [PATCH 03/14] FS-Cache: Provide an add_wait_queue_tail() function " David Howells
2007-08-09 16:04 ` [PATCH 04/14] FS-Cache: Generic filesystem caching facility " David Howells
2007-08-09 16:05 ` [PATCH 05/14] CacheFiles: Add missing copy_page export for ia64 " David Howells
2007-08-09 16:05 ` [PATCH 06/14] CacheFiles: Add a hook to write a single page of data to an inode " David Howells
2007-08-09 16:05 ` [PATCH 07/14] CacheFiles: Permit the page lock state to be monitored " David Howells
2007-08-09 16:05 ` [PATCH 08/14] CacheFiles: Export things for CacheFiles " David Howells
2007-08-09 16:05 ` [PATCH 09/14] CacheFiles: Permit a process's create SID to be overridden " David Howells
2007-08-09 17:04 ` Casey Schaufler
2007-08-09 18:07 ` David Howells
2007-08-09 18:51 ` Casey Schaufler
2007-08-09 16:05 ` [PATCH 10/14] CacheFiles: Add an act-as SID override in task_security_struct " David Howells
2007-08-09 16:05 ` [PATCH 11/14] CacheFiles: Permit an inode's security ID to be obtained " David Howells
2007-08-09 17:07 ` Casey Schaufler
2007-08-09 17:22 ` Stephen Smalley
2007-08-09 17:59 ` Casey Schaufler
2007-08-09 18:06 ` David Howells
2007-08-09 18:50 ` James Morris
2007-08-09 19:07 ` David Howells
2007-08-09 19:34 ` James Morris [this message]
2007-08-09 20:33 ` Casey Schaufler
2007-08-10 9:22 ` David Howells
2007-08-09 18:16 ` James Morris
2007-08-09 18:21 ` David Howells
2007-08-09 18:42 ` James Morris
2007-08-09 16:05 ` [PATCH 12/14] CacheFiles: Get the SID under which the CacheFiles module should operate " David Howells
2007-08-09 16:05 ` [PATCH 13/14] CacheFiles: A cache that backs onto a mounted filesystem " David Howells
2007-08-09 16:05 ` [PATCH 14/14] NFS: Use local caching " David Howells
2007-08-09 18:24 ` Trond Myklebust
2007-08-09 18:52 ` David Howells
2007-08-09 19:25 ` Trond Myklebust
2007-08-10 14:04 ` David Howells
2007-08-10 16:07 ` Trond Myklebust
2007-08-09 19:15 ` David Howells
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=Pine.LNX.4.64.0708091223330.19611@us.intercode.com.au \
--to=jmorris@namei.org \
--cc=akpm@osdl.org \
--cc=casey@schaufler-ca.com \
--cc=dhowells@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=steved@redhat.com \
--cc=torvalds@osdl.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 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).