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)
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
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/
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$ sudo -u igoweb ls
ls: .: stale NFS file handle
ls: .: stale NFS file handle
sm28$ cd $PWD
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
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):
Steps to Reproduce:
1. Make directories:
chmod o-rwx .
chmod o+rwx test
2. Go to test dir, make sure you can read it:
3. sudo to another user (who is *not* in your group), and create stale
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.
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.