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: <Pine.LNX.4.64.0708311317260.8223@raven.themaw.net>
Date:	Fri, 31 Aug 2007 13:38:46 +0800 (WST)
From:	Ian Kent <raven@...maw.net>
To:	'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>
cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	Frank van Maarseveen <frankvm@...nkvm.com>,
	Hua Zhong <hzhong@...il.com>,
	'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org, Ion Badulescu <ionut@...ula.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: recent nfs change causes autofs regression

On Thu, 30 Aug 2007, Linus Torvalds wrote:
> 
> 
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> > 
> > It did not. The previous behaviour was to always silently override the
> > user mount options.
> 
> ..so it still worked for any sane setup, at least.
> 
> You broke that. Hua gave good reasons for why he cannot use the current 
> kernel. It's a regression.
> 
> In other words, the new behaviour is *worse* than the behaviour you 
> consider to be the incorrect one.
> 

This all came about due to complains about not being able to mount the 
same server file system with different options, most commonly ro vs. rw 
which I think was due to the shared super block changes some time ago. 
And, to some extent, I have to plead guilty for not complaining enough 
about this default in the beginning, which is basically unacceptable for 
sure.

We have seen breakage in Fedora with the introduction of the patches and 
this is typical of it. It also breaks amd and admins have no way of 
altering this that I'm aware of (help us here Ion).

I understand Tronds concerns but the fact remains that other Unixs allow 
this behaviour but don't assert cache coherancy and many sysadmin don't 
realize this. So the broken behavior is expected to work and we can't 
simply stop allowing it unless we want to attend a public hanging with us 
as the paticipants.

There is no question that the new behavior is worse and this change is 
unacceptable as a solution to the original problem.

I really think that reversing the default, as has been suggested, 
documenting the risk in the mount.nfs man page and perhaps issuing a 
warning from the kernel is a better way to handle this. At least we will 
be doing more to raise public awareness of the issue than others.

Ian
-
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/