Bug 4589 - nfs cache permissions
nfs cache permissions
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-08-18 12:41 EDT by mhaller
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
Description mhaller 1999-08-18 12:41:53 EDT
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
/mnt/etc/sudoers

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

[root@digerati /mnt/etc]# id
uid=0(root)
gid=0(root)groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)


        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
/etc/inittab
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
file

[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)     =
19
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 13:00:59 EDT
Can you verify that this problem exists with the latest Raw Hide
packages
	kernel-2.2.11
	knfsd-1.4.7
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 19:50:59 EDT
can't find knfsd-1.4.7
rpmfind.net has 1.4.6
any pointers?
Comment 3 mhaller 1999-08-26 13:53:59 EDT
tried this with the knfsd-1.4.7
Comment 4 mhaller 1999-08-26 13:54:59 EDT
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 10:47:59 EDT
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:
.
http://db.geocrawler.com/archives/3/35/1999/4/0/1612757/
.
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
problem.
.
Can these be incorporated into he 2.2.5 kernel rpm updates?
.
reducing severity, thanks

Note You need to log in before you can comment on or make changes to this bug.