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: <1188535485.6626.85.camel@heimdal.trondhjem.org>
Date:	Fri, 31 Aug 2007 00:44:45 -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 Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
> 
> 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).

It did not. The previous behaviour was to always silently override the
user mount options.

> 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.

This is _not_ a kernel policy decision. The kernel is simply informing
the user that it cannot fulfil the mount request as specified. Exactly
why do you think that NFS should be any different from other filesystems
when it comes to this?

AFAIK, every other filesystem will give you an EBUSY if you try to mount
a partition with -oro if you are already mounting somewhere else with
-orw. Every filesystem will give you an EBUSY if you try to mount the
partition with -oacl if it is mounted somewhere else with -onoacl. The
reason: exactly the same as NFS, the caches cannot remain consistent
when you try to mount two different super blocks that both refer to the
same underlying filesystem.

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/