Bug 4589

Summary: nfs cache permissions
Product: [Retired] Red Hat Linux Reporter: mhaller
Component: kernelAssignee: Cristian Gafton <gafton>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description mhaller 1999-08-18 16:41:53 UTC
I have noticed a problem with either the nfs or the kernel
caching code which exhibits itself when doing a setgid()
before a read on an nfs mounted file.  Then subsequent reads
on that same file don't obey the permissions of the nfs
file, as they get something out of a cache.

The program in this case is sudo; sudo has been recompiled
to set the gid to a non-0 gid before it attempting to read
its configuration file which in this case is nfs mounted on
/mnt/etc - full path /mnt/etc/sudoers w/ 440 perms 0:16
uid:gid. The nfs export was exported without root uid
mapping, so root should come across as nobody, normally.
However, when root comes across through sudo should be uid 0
and gid 16 in my setup.  sudo fails when reading the file,
but only if it is larger than the nfs read block size; then
subsequent cat's of that file fail with inconsistant errors
but only after displaying the first block of the file which
root should NOT be able to do.

        So first just check the perms;

[root@digerati /mnt/etc ]# ls -al sudoers
-r--r-----   1 root     sudoers     11589 Aug  9 16:50

        I am 0:0 and should be mapped to 99:99 on the read
over nfs

[root@digerati /mnt/etc]# id

        And it denies as expected

[root@digerati /mnt/etc]# cat sudoers
cat: sudoers : Permission denied

        sudo fails on the padded sudoers file
	(if this file is not padded (<4096) it does not 		fail)

[root@digerati /mnt/etc]# sudo cat
input in flex scanner failed

        Now we can read some of the file - not expected!

[root@digerati /mnt/etc]# cat sudoers
permission denied but only after displaying a portion of the

[root@digerati /mnt/etc]# cat sudoers 1>/tmp/sudoers-4096
cat: sudoers: Input/output error

        where now /tmp/sudoers-4096 contains the first 4096
	bytes from the /mnt/etc/sudoers file

Subsequent running the command gives you alternating errors

[root@digerati /mnt/etc]# cat sudoers 1>/dev/null
cat: sudoers: Permission denied
[root@digerati /mnt/etc]# cat sudoers 1>/dev/null
cat: sudoers: Input/output error
So an strace of the sudo cat shows sudo is in a loop
to read in 4096 blocks
read(3, "# sudoers file.\n#\n# This file "..., 4096) = 4096
write(1, "# sudoers file.\n#\n# This file "..., 4096) = 4096
read(3, 0x804ad78, 4096)                = -1 EACCES
(Permission denied)
write(2, "cat: ", 5cat: )                    = 5
write(2, "/mnt/etc/sudoers", 16/mnt/etc/sudoers)        = 16
write(2, ": Permission denied", 19: Permission denied)     =
write(2, "\n", 1
Also of note if I logout as root and become a normal user
who shouldn't be able to read that file it also displays
the first 4096 bytes and fails in the same way.
This happens with 2.2.11 and knfsd ... 1.4.6
[mhaller@digerati /sbin]$ /usr/sbin/rpc.mountd -v
kmountd 1.4.6 (0.4.22)
I had submitted this to the authors with mixed response, so
I am submitting it here official.
Thanks very much!!!

Comment 1 Jeff Johnson 1999-08-18 17:00:59 UTC
Can you verify that this problem exists with the latest Raw Hide
You might have to wait a bit for the kernel to get to Raw Hide.
The latest knfsd patches are just being applied ...

Comment 2 mhaller 1999-08-19 23:50:59 UTC
can't find knfsd-1.4.7
rpmfind.net has 1.4.6
any pointers?

Comment 3 mhaller 1999-08-26 17:53:59 UTC
tried this with the knfsd-1.4.7

Comment 4 mhaller 1999-08-26 17:54:59 UTC
problem still exists with knfsd-1.4.7-2 and knfsd-clients-1.4.7-2
with kernel 2.2.11

Comment 5 mhaller 1999-08-30 14:47:59 UTC
The problem was incorrectly reported initially.  When switching to a
uid with the wrong credentials you get permission denied messages.
The problem lies in the fact that linux nfs is using different
credentials reads/writes as it did for the initial open.  It is
covered by a bugfix submitted to the kernel mailing list:
This patch has been included inthe nfs patches provided by Alan Cox
2.2*ac kernels, and with 2.2.11-ac7 for example I cannot reproduce the
Can these be incorporated into he 2.2.5 kernel rpm updates?
reducing severity, thanks