linux-kernel - Re: recent nfs change causes autofs regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1188587029.19730.39.camel@heimdal.trondhjem.org>
Date:	Fri, 31 Aug 2007 15:03:49 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Frank van Maarseveen <frankvm@...nkvm.com>,
	Hua Zhong <hzhong@...il.com>,
	'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org
Subject: Re: recent nfs change causes autofs regression

On Fri, 2007-08-31 at 10:01 -0700, Linus Torvalds wrote:
> 
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > The best I can do given the constraints appears to be to have the kernel
> > first look for a superblock that matches both the fsid and the
> > user-specified mount options, and then spawn off a new superblock if
> > that search fails.
> 
> I think this is probably acceptable to get roughly the old behaviour, but 
> I still think it's a bit stupid.
> 
> What happens at "mount -o remount,..." time?
> 
> The fact is, the whole "match the fsid and user mount options, and re-use 
> the mount" sounds like it's trying to solve a problem that doesn't need 
> solving. If the user really wants to duplicate the mount, he really should 
> be using a a bind-mount instead.
> 
> In other words, let's assume that the user has /some/nfs/mount mounted 
> over NFS, and wants to re-mount it (or even just a subset of it) somewhere 
> else, the sane thing to do is not to mount it again, but to just do
> 
> 	mount --bind /some/nfs/mount/subdir /new/mount/place
> 
> instead. That *guarantees* that the low-level filesystem uses the same 
> flags, and it also means that things like re-mounting have sane and 
> well-defined semantics, and will fail or succeed predictably.

I agree for the cases where you can use bind mounts, however you can't
always do that.

Consider the fairly common setup where /foo, /foo/a, /foo/b are all on
the same filesystem on the server, but only /foo/a and /foo/b are
exported.
There can be plenty of files that are contain hard links in both
directories, but because you cannot mount the parent, /foo, you will not
be able to ensure that these common files are cached to the same inode
(which they need to be).

IOW: with this scenario, you can't ensure that local posix semantics
hold (i.e. that if my client is the only user, then the filesystem will
behave as if it were a posix filesystem). That would be a major
regression.

> In contrast, if a user wants to create a new NFS mount, it really should 
> be independent of the old one, because that's (a) what other systems do, 
> and (b) also makes the semantics of re-mounting it with other flags be 
> clear and unambiguous (ie the remount has nothing what-so-ever to do with 
> the independent NFS mount).

(a) I'm not sure that is true: see (b).
(b) You gain remount clarity at the expense of local posix filesystem
correctness.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/