Bug 7385

Summary:	nfs4 broken in vanilla-sources 2.6.19
Product:	File System	Reporter:	Huemi (t.himmelbauer)
Component:	NFS	Assignee:	Trond Myklebust (trondmy)
Status:	CLOSED CODE_FIX
Severity:	normal
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	vanilla-sources 2.6.19	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	NFSv4: Fix thinko in fs/nfs/super.c

Description Huemi 2006-10-19 06:31:41 UTC

Most recent kernel where this bug did not occur: 2.6.18
Distribution: gentoo (vanilla_sources)
Hardware Environment: 
Software Environment: nfs-utils 1.0.10, vanilla-sources 2.6.19
Problem Description:
It is not possible to mount a nfs4 export. It fails with the error message can't
read superblock.
Steps to reproduce:
install gentoo with vanilla-sources 2.6.19_rc1 or rc2 and nfs-utils 1.0.10 and
unmask the necessary dependencies

entries in /etc/export
/export *(rw,fsid=0,insecure,no_subtree_check,sync)
/export/bla *(rw,nohide,root_squash,insecure,no_subtree_check,async)
/export/user *(rw,nohide,root_squash,insecure,no_subtree_check,async

/export and /export/bla have group and owner root and chmod 0777

commands:
modprobe nfs
/etc/init.d/nfs start
/etc/init.d/nfsmount start
mount -t nfs4 127.0.0.1:/bla /bla

Watch the computer hanging and then responding with an error in
/var/log/messages that the server wouldn't respond and mount responding with
"... can't read superblock".

The problem I had why I tested the kernel was that it is possible to read and
write files on an nfs4 mount as a normal user having none permissions (chmod
0000) but owning the file. But I can't test it on kernel 2.6.19 because I can't
mount nfs4 exports.

Comment 1 Trond Myklebust 2006-10-19 06:41:08 UTC

Created attachment 9303 [details]
NFSv4: Fix thinko in fs/nfs/super.c

Known bug due to a combination of a bug in Gentoo's implementation of "mount"
for NFSv4, and a kernel-side "fix" that was incorrect.

Comment 2 Huemi 2006-10-19 07:05:54 UTC

Thanks for the patch.

Using the patch I was able to test my permission problem with vanilla-sources
2.6.19_rc2 and even there it exists. I'm able to read and write from and to my
own files even with permissions set to 0000. Try it on a local file system (or
with nfs) and you will find out that this is not the usual filesystem
behaviour. So I think nfs4 has a bug regarding file permission handling. It is
not a real security bug, because you can't read or write files of others without
appropriate permissions, but your programs can overwrite your files without
changing permissions.

Comment 3 Trond Myklebust 2006-10-19 07:59:20 UTC

That is an entirely different issue that has nothing to do with the bug you
reported above.

All NFS servers have traditionally implemented this policy because NFSv2 and
NFSv3 are stateless (there is no protocol equivalent of open() or close()). In
order to make open("foo", O_CREATE|O_WRITE, 0) work, you have to allow writing
by the owner to these files.

NFSv4 introduces state, and has both OPEN and CLOSE, so it can remove the
'writeable 0 mode file' hack. I believe Bruce already has a patch for this in
his latest CITI_ALL series.

Comment 4 Trond Myklebust 2006-10-19 08:23:56 UTC

To clarify what I meant above: I believe a fix for the permission issue is
available, but if you would still like to report it in the bugzilla, then please
file it under a new entry, so that we keep it separate from the mount problem.