Bug 139444 - mode of device nodes and sockets on NFS filesystems
mode of device nodes and sockets on NFS filesystems
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-15 18:36 EST by David Lehman
Modified: 2010-10-21 22:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-22 09:18:52 EDT
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 David Lehman 2004-11-15 18:36:21 EST
Description of problem:
When the mode of a device node (eg: sda) or a socket on an NFS filesystem are
changed (on the client), the change succeeds, but then is overwritten within 30
seconds by the mode of the server's copy of the node/sock. It seems either the
chmod should fail or it should be recognized at sync time (and therefore
preserved locally). I doubt anyone expects it to change the server's copy of the
 file.

Version-Release number of selected component (if applicable):
kernel-smp-2.4.21-20.EL

How reproducible:
Always

Steps to Reproduce:
1. do either 'mksock foo' or '/dev/MAKEDEV -d `pwd` sda' on an NFS filesystem
2. chmod the new node/sock to 0777
3. (quickly) verify the mode now 0777
4. wait 30 seconds (at most)
5. re-observe the mode
  
Actual results:
the mode will have been reverted to the mode it was created with (0755)

Expected results:
the mode of the local copy is either immutable in the first place or stays
changed once chmod has succeeded

Additional info:
Comment 3 Bastien Nocera 2005-02-17 09:49:54 EST
Dave, could you verify whether the mode of the device is set properly at any
time on the server? Which OS and revision is running on the server?
Do you know whether the mount is mounted with noac, or sync?
Would you be able to gather a tcpdump of the file creation, chmod, and
subsequent ls?
Comment 13 Steve Dickson 2005-06-22 09:18:52 EDT
Well it appears there is not much we can do about this
because of how socket are created.

When a socket is created, an inode is also allocated. In the inode
there is an 'inode_operations' field that is set,  usually by the
file system, to point to the appropriate file system specific operations. 
In the case  of NFS, these operations causes Over-The-Wire operations
then things like chmod are done.

Now the problem is the inode_operations field in the inode (that
is attached to the socket) are not being set with the NFS
specific operations, so when the chmod is done the NFS
opts are never called which means the permission bits are
only set locally (i.e. the server is never told of the change).

When the local cache expires, NFS will refresh its cache
with the server bits which in this case are the old
permission bits. Thats why the permission bits revert
after a few seconds. 

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