Bug 139444

Summary:	mode of device nodes and sockets on NFS filesystems
Product:	Red Hat Enterprise Linux 3	Reporter:	David Lehman <dlehman>
Component:	kernel	Assignee:	Steve Dickson <steved>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	petrides, riel, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-06-22 13:18:52 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:

Description David Lehman 2004-11-15 23:36:21 UTC

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 14:49:54 UTC

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 13:18:52 UTC

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.