Red Hat Bugzilla – Bug 118816
sudo with proper protections causes stale NFS file handles
Last modified: 2007-11-30 17:07:00 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8 Description of problem: I have two RHEL3 systems sharing NFS. "sudoers" lets me run anything as user "igoweb". I (user "wms") created a directory "~wms/test" with these protections: sm28$ ls -ld ~wms ~wms/test drwx------+ 18 wms wms 4.0K Mar 21 00:46 /home/wms/ drwxrwxr-x 2 wms wms 4.0K Mar 21 00:46 /home/wms/test/ sm28$ Note that /home/wms/test's protections say that anybody should have r-x access, but the parent directory will actually prevent user "igoweb" from using that (~wms does have an ACL, but it the ACL does not allow "igoweb" in.) I put a file "dummy" in ~wms/test just so that "ls" will show something. Now, from the ~wms/test directory, starting as "wms", the following strange sequence happens: sm28$ ls dummy sm28$ sudo -u igoweb ls ls: .: stale NFS file handle sm28$ ls ls: .: stale NFS file handle sm28$ cd $PWD sm28$ ls dummy sm28$ In other words, when I try to view ~wms/test as "igoweb", I'm told the file handle is stale (instead of being told that I don't have access, as I should be told). Even once I am "wms" again, I am still told that I have a stale file handle! If I do "chmod 700 ~wms/test", then I get the proper error message as "igoweb" and things work fine when I return to be "wms" again. If I "chmod o+rx ~/wms", then I properly see the contents of the directory both as "wms" and as "igoweb" and get no errors at all. I hope that this is easy to reproduce from what I said, but just in case I've attached an ethereal log. During the log I ran the command: sm28$ ls ; sleep 1 ; sudo -u igoweb ls ; sleep 1 ; ls ; sleep 1 ; cd $PWD ; sleep 1 ; ls So by looking at the timestamp on the packets, it's easy to see which NFS packets are from which command since they are almost exactly 1 second apart. (There's some MySQL replication TCP traffic mixed in also, but that's pretty easy to separate out when you are viewing the log). Other testing has shown that the change in "sudo" is not necessary; if I just have "igoweb" logged in in a different window, trying to access ~wms/test from "igoweb"'s window will make the "wms" window start getting stale NFS file handles. Version-Release number of selected component (if applicable): nfs-utils-1.0.6-7.EL, kernel-2.4.21-9.0.1.EL How reproducible: Always Steps to Reproduce: 1. Make directories: cd ~ chmod o-rwx . mkdir test chmod o+rwx test touch ~/test/dummy 2. Go to test dir, make sure you can read it: cd ~/test ls 3. sudo to another user (who is *not* in your group), and create stale handle: sudo -u otherUser ls 4. After sudo, do "ls" again to show that you just can't access that directory any more Actual Results: Steps 3 and 4 returned "Stale NFS file handle" Expected Results: "Permission Denied" in step 3 and a normal listing in step 4. Additional info:
Created attachment 98722 [details] ethereal dump while creating stale NFS file handle Please ignore the MySQL replication traffic. NFS traffic is easily assigend to commands as follows: 0secs --> "ls" command as user "wms" 1sec --> "sudo -u igoweb ls" 2sec --> "ls" as "wms" again 3sec --> "cd $PWD" 4sec --> "ls" as "wms" a third time
Is this still an issue on recent RHEL3 releases? Say, RHEL3U9?
Wow, in the past 3+ years I'd forgotten about this bug. I don't even run RHEL3 any more, I upgraded my hardware and switched to RHEL4 at one point. I just checked, the bug is not present under RHEL4.
Sorry, this one seemed to have slipped through the cracks. Since I havent heard of anyone else complaining about this (even on RHEL3), I'm thinking we'll close this with an INSUFFICIENT_DATA. If it reoccurs then we'll plan to reopen it.