From: Eric Paris <eparis@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nfs@vger.kernel.org, selinux <selinux@tycho.nsa.gov>,
linux-security-module@vger.kernel.org, steved@redhat.com,
jlayton@redhat.com, sds@tycho.nsa.gov, jmorris@namei.org,
casey@schaufler-ca.com, trond.myklebust@fys.uio.no,
chuck.lever@oracle.com, linux-fsdevel@vger.kernel.org
Subject: Re: NFS/LSM: allow NFS to control all of its own mount options
Date: Tue, 19 Feb 2008 17:36:46 -0500 [thread overview]
Message-ID: <1203460606.2928.127.camel@localhost.localdomain> (raw)
In-Reply-To: <20080219222408.GB10656@infradead.org>
On Tue, 2008-02-19 at 17:24 -0500, Christoph Hellwig wrote:
> Please don't introduce a special case for just nfs. All filesystems
> should control their mount options, so please provide some library
> helpers for context= handling and move it into all filesystems that
> can support selinux.
A library helper that looks like what?
Only NFS knows how it is storing that mount option in its blobs. Only
NFS knows how to translate its blob into the generic LSM interface
needed to set security options. I'd say the solution is going to have
to be very much NFS specific.
Both in kernel LSMs already provide methods for dealing with mount
options for filesystems that use text strings (see the
security_sb_copy_data stuff called from vfs_kern_mount()). How is this
'library' going to deal with anything other than a text string, and if
that's all it deals with we already have that. NFS just can't use it
because it isn't using a string for mount data. I'm sure I'm just
misunderstanding how to design your solution...
-Eric
next prev parent reply other threads:[~2008-02-19 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1203457094.2928.113.camel@localhost.localdomain>
[not found] ` <1203457094.2928.113.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-02-19 22:24 ` NFS/LSM: allow NFS to control all of its own mount options Christoph Hellwig
2008-02-19 22:36 ` Eric Paris [this message]
2008-02-19 23:18 ` Casey Schaufler
2008-02-20 0:25 ` James Morris
2008-02-20 13:48 ` Stephen Smalley
2008-02-20 10:08 ` Miklos Szeredi
2008-02-20 13:50 ` Stephen Smalley
[not found] ` <1203515410.9902.128.camel-/ugcdrsPCSfIm9DtXLC9OUVfdvkotuLY+aIohriVLy8@public.gmane.org>
2008-02-20 13:56 ` Eric Paris
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=1203460606.2928.127.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=chuck.lever@oracle.com \
--cc=hch@infradead.org \
--cc=jlayton@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=steved@redhat.com \
--cc=trond.myklebust@fys.uio.no \
/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).