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]

Date:	Sat, 01 Sep 2007 20:58:25 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Trond Myklebust <trond.myklebust@....uio.no>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

Trond Myklebust wrote:
> On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
>> 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.
> 
> 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. The attached patch does just that.
> 
I'm glad I read the whole thread, because when I saw it earlier and 
didn't respond, this was the question I had, why not replace the error 
with forcing "nosharecache" on, which is essentially what you have done.

> Note that this is not the same as specifying nosharecache everywhere
> since nosharecache will never attempt to match an existing superblock.
> 
> Finally, for the record: I still feel very uncomfortable about not being
> able to report the state of the client setup back to the sysadmin.
> AFAIK, the only way to do so is to stat the mountpoints, and compare the
> device ids.
> 
Since clients may not know the server setup, and it may change for 
policy or error recovery reason, I think this patch is needed.

The cases I think are common are:

1 - single export, multiple client mounts

export /base - rw

mount /base/share - ro		[ client enforces r/o or not ]
mount /base/upload - rw

2 - export parts of a filesystem (/base) [ server enforces access ]

export /base/share - ro		[ hopefully really r/o on client ]
export /base/upload - rw	[ should work for write ]

3 - mount the same f/s with different permissions on client

export /base - rw

mount /base on point1 - rw	[ hopefully really r/w ]
mount /base on point2 - ro	[ hopefully r/o ]

I consider this *really* bad practice, but I have seen it in enough 
places to know others don't agree. It assumes the client will protect 
the r/o data.

4 - export f/s and part of f/s

export /base/ - ro
export /base/upload - rw

clients may mount one or both, with the upload directory as part of base 
or elsewhere. What will happen here?

> Trond


-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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/