From: Eric Paris <eparis@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: jmorris@namei.org, casey@schaufler-ca.com,
selinux <selinux@tycho.nsa.gov>,
linux-security-module@vger.kernel.org
Subject: Re: How to handle NFS and conflicting mount options
Date: Wed, 05 Mar 2008 09:54:21 -0500 [thread overview]
Message-ID: <1204728861.3216.212.camel@localhost.localdomain> (raw)
In-Reply-To: <1204728406.1397.36.camel@moss-spartans.epoch.ncsc.mil>
On Wed, 2008-03-05 at 09:46 -0500, Stephen Smalley wrote:
> On Wed, 2008-03-05 at 09:42 -0500, Eric Paris wrote:
> > On Wed, 2008-03-05 at 09:27 -0500, Jeff Layton wrote:
> > > On Wed, 05 Mar 2008 09:11:10 -0500
> > > Eric Paris <eparis@redhat.com> wrote:
> >
> > > > This is going to use the same superblock but the context= needs to the
> > > > same. There is no was to reconcile the 2, so we just reject the second
> > > > mount.
> > > >
> > >
> > > We could just not share superblocks in that case. Maybe add a new
> > > condition to nfs_compare_mount_options()? When that returns 0 now, I
> > > believe we spin off a new superblock.
> >
> > I'll add it to my list of things to look at for .26.
> > nfs_compare_mount_options doesn't have all the data the LSM would need
> > but nfs_compare_super probably does. The selinux code is not going to
> > change in this regard since most FS don't have such a nice 'just use a
> > new one' option and the LSM should make sure it isn't doing things under
> > the covers the user wasn't expecting. Using this feature is not going
> > to clean up the necessity for that little if statement you were looking
> > at but I can probably make NFS and multiple lsm options play nicer
> > together in a future patch.
> >
> > -Eric
> >
> > [pulled from NFS list to just the security people]
> >
> > Does this even make sense? Should we allow:
> >
> > mount -o context=context1 server:/export /mnt/mnt1
> > mount -o context=context2 server:/export /mnt/mnt2
> >
> > Same data different label?
>
> No, that's contrary to the goals of labeled MAC.
>
> > How about
> >
> > mount -o context=context1 server:/export/subdir1 /mnt/mnt1
> > mount -o context=context2 server:/export/subdir2 /mnt/mnt2
> >
> > Here we have the same SB but different data and different labels.
>
> This one would be nice, as it would allow for e.g. different user home
> directories to be mounted at different contexts.
>
> > I
> > think the user can easily get this by just setting of them to have a
> > timeout of 119 seconds and the second to 120, so maybe we should just go
> > ahead and explicitly allow it? I don't know, how do people feel about
> > having NFS spin off a new SB if security mount options don't match?
>
> For same data, no. For different data, yes.
> Distinguishing the two may be hard on the client.
Hard? I'm going to have to go with 'impossible' on this one. I think
I'm going to not implement anything to make NFS explicitly handle
conflicting mount options and just bomb in the selinux code like we do
today. If someone really wants situation 2 they are going to need to
know what they are doing and find this conversation where I give the
hint about just using conflicting NFS mount options to get the multiple
superblocks.
-Eric
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2008-03-05 14:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-03 19:42 [PATCH -v2] NFS/LSM: allow NFS to control all of its own mount options Eric Paris
2008-03-03 19:42 ` Eric Paris
2008-03-03 19:38 ` Dave Quigley
2008-03-03 19:38 ` Dave Quigley
[not found] ` <1204573122.14520.90.camel-88+Bj4OksMGWPftkNcioYDMZycKHmlmlfvIqQ387n9k@public.gmane.org>
2008-03-03 20:10 ` Eric Paris
2008-03-03 20:10 ` Eric Paris
2008-03-03 20:10 ` Eric Paris
2008-03-03 19:51 ` Dave Quigley
2008-03-03 19:51 ` Dave Quigley
2008-03-04 22:54 ` James Morris
2008-03-04 22:54 ` James Morris
2008-03-05 13:48 ` Jeff Layton
2008-03-05 14:11 ` Eric Paris
2008-03-05 14:11 ` Eric Paris
[not found] ` <1204726270.3216.196.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-03-05 14:27 ` Jeff Layton
2008-03-05 14:27 ` Jeff Layton
[not found] ` <20080305092758.1bfe9687-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2008-03-05 14:34 ` Eric Paris
2008-03-05 14:34 ` Eric Paris
2008-03-05 14:34 ` Eric Paris
2008-03-05 14:42 ` How to handle NFS and conflicting " Eric Paris
2008-03-05 14:46 ` Stephen Smalley
2008-03-05 14:54 ` Eric Paris [this message]
2008-03-05 17:15 ` Casey Schaufler
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=1204728861.3216.212.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/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.