From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp
Date: Sat, 05 May 2007 13:17:52 -0400
Message-ID: <1178385472.6561.43.camel@heimdal.trondhjem.org>
References: <46269362.5040608@amd.com>
	<1176948355.6422.72.camel@heimdal.trondhjem.org>
	<4627B3DD.5050409@amd.com>
	<1177007479.6623.14.camel@heimdal.trondhjem.org>
	<4627D303.8060009@amd.com>
	<1177020662.6628.30.camel@heimdal.trondhjem.org>
	<4627EBFC.2090704@amd.com>
	<462CFC92.2080201@amd.com>  <463B97E6.4030009@amd.com>
	<1178314889.6533.19.camel@heimdal.trondhjem.org>
	<1178379473.4559.24.camel@raven.themaw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Paul Krizak <paul.krizak@amd.com>, nfs@lists.sourceforge.net
To: Ian Kent <raven@themaw.net>
In-Reply-To: <1178379473.4559.24.camel@raven.themaw.net>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Sat, 2007-05-05 at 23:37 +0800, Ian Kent wrote:
> On Fri, 2007-05-04 at 17:41 -0400, Trond Myklebust wrote:
> > On Fri, 2007-05-04 at 15:30 -0500, Gregory Baker wrote:
> > > Are all NFS options from an export inherited by subsequent mounts since 
> > > the upstream commit 54ceac4515986030c2502960be620198dd8fe25b?
> 
> I wish I'd payed more attention to the shared superblock patches but I
> was consumed by autofs at the time. Even so I likely wouldn't have
> realized the implications.
> 
> > > 
> > > I'm pasting an email from a colleague at AMD that's also trying to gain 
> > > an understanding of the new mount behavior (Paul Krizak)...
> > > 
> > > Thanks,
> > > 
> > > --Greg
> > 
> > If two mounts refer to the same _filesystem_ (i.e. the NFS server
> > exports them with the same value for the 'fsid' attribute), then they
> > will share the same options.
> > 
> > If you are trying to use different security models for different
> > mountpoint, you should in any case be considering using different
> > filesystems on the server: NFS filehandles are normally not tied to a
> > pathname since they are required to remain the same after a
> > cross-directory rename().
> > The exception is if the file and the directory live on different
> > filesystems (since then a cross-directory rename() is not permitted
> > anyway) and so the filehandles will usually encode the fsid in some way
> > or form.
> > 
> > IOW: if /foo and /bar refer to directories the same filesystem, then the
> > server cannot figure out if the file baz.txt lives in one or the other
> > directory. Giving /foo and /bar different security permissions is really
> > the same as giving _both_ sets of permissions. Even if the server
> > encodes the permissions in the filehandle (usually by recording the
> > export point) then the client is free to spoof a filehandle for the same
> > file with the other set of permissions.
> 
> I don't see how doing this on the client adds any security at all as the
> spoofing issue is still present. It does prevent people from being able
> to do read-only mounts for administrative purposes. Like when used to
> guard against accidents rather than provide real security. But then I
> see this isn't the only reason these patches were so important.

Why are people arguing that NFS should be working in a completely
different fashion to all other filesystems? Fix the VFS to allow
read-only bind mounts, and NFS will work just fine with that.

The problem with the old behaviour was that it screwed people over by
causing file caching to be inconsistent on the same client. IOW: if I
wrote to the file on the read-write partition, then those changes would
not be immediately guaranteed to be visible to a process that happened
to read the file on the read-only partition.

> So is there "anything at all" we can do to change this behavior now,
> apart from teaching mount to about it. Having the /etc/mtab
> and /proc/mounts recording different mount options for a mount is wrong.
> 
> How should mount(8) handle the situation?

I'd rather like to have mount(2) handle the situation by returning an
error if the mount options cannot be satisfied.

Trond

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs