|Summary:||nfs cache permissions|
|Product:||[Retired] Red Hat Linux||Reporter:||mhaller|
|Component:||kernel||Assignee:||Cristian Gafton <gafton>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|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 /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 17:00:59 UTC
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 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: . 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