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: <alpine.LFD.0.999.0708302038310.25853@woody.linux-foundation.org>
Date:	Thu, 30 Aug 2007 20:49:34 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>,
	Frank van Maarseveen <frankvm@...nkvm.com>
cc:	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 Thu, 30 Aug 2007, Trond Myklebust wrote:
> 
> Which is better than having it fail silently, or giving you a mount with
> the wrong mount options.

No, Trond.

That commit gets reverted or fixed. It's a regression, and your theories 
that it's "better" that way are obviously broken.

It's obviously broken because you seem to say that you know better, even 
though you also admit that:

  "How is the NFS client to know that these directories are disjoint, or
   that no-one will ever create a hard link from one directory to another? 
   To my knowledge, the only way to ensure this is to put them on 
   different disk partitions."

the point being that you just disallowed people from doing things that are 
sane but _potentially_ dangerous. That's now how we work. The UNIX way sis 
to give people rope - if you cannot *prove* that what they are doing is 
wrong, then you damn well better not disallow it.

No regressions, Trond. Especially not for stuff that used to work, was 
used, and that could be sanely expected to work (which this *definitely*
sounds like).

Please send in a fix. If the fix involves making "nosharecache" the 
default, then that is better than making policy decisions like this in the 
kernel. The kernel should do what the user asks and not put in unnecessary 
roadblocks.

Hua - that said, I don't actually see why the commit you bisected to has 
anything to do with the issue being discussed. Can you double-check that 
it's literally that particular commit that breaks for you (you could try 
just reverting that commit).

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