Bug 118816

Summary: sudo with proper protections causes stale NFS file handles
Product: Red Hat Enterprise Linux 3 Reporter: William Shubert <wms>
Component: nfs-utilsAssignee: Jeff Layton <jlayton>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: staubach, steved
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-17 16:37:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ethereal dump while creating stale NFS file handle none

Description William Shubert 2004-03-21 01:02:18 UTC
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:

Comment 1 William Shubert 2004-03-21 01:04:35 UTC
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

Comment 2 Jeff Layton 2007-07-17 11:00:36 UTC
Is this still an issue on recent RHEL3 releases? Say, RHEL3U9?


Comment 3 William Shubert 2007-07-17 16:07:27 UTC
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.

Comment 4 Jeff Layton 2007-07-17 16:37:29 UTC
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.