Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 623054 - [RFE] SGID processing by NFS-client
[RFE] SGID processing by NFS-client
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.7
All Linux
low Severity low
: rc
: ---
Assigned To: Jeff Layton
Red Hat Kernel QE team
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-11 04:14 EDT by Issue Tracker
Modified: 2014-06-18 03:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-16 11:55:14 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 Issue Tracker 2010-08-11 04:14:04 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2010-08-11 04:14:06 EDT
Event posted on 2010-08-11 10:12 CEST by rdassen

2) Nature Of Problem:
the Linux NFS client does not send anything special to the server
expecting that the server itself will check the SGID bit and create a file
with the needed group.  In this case everything works as expected if the
NFS-server is running on Linux. The customer has to work with some kind of
MS Windows as NFS server, which is not able to handle the SGID check.  The
request is to have the Linux client send the SGID infomration to the
server.

3) Business Requirements Satisfied By Request:
The customer can successfully use a Windows based NFS server that honors
the SGID bit properly.

4) Functional Requirements That Are Not Presently Possible:
cannot mount and write to a Windows NFS share that will set the group
correctly on new files.

5) What Will Success Look Like:
SGID on files will be set correctly from the Linux client and seen on the
NFS server.

6) Desired Release Vehicle:
RHEL update.



This event sent from IssueTracker by rdassen  [SEG - Feature Request]
 issue 1186003
Comment 3 Issue Tracker 2010-08-11 04:23:26 EDT
Event posted on 2010-07-26 19:54 CEST by asidorenko

File uploaded: nfs_create-request-hpux.txt

This event sent from IssueTracker by rdassen 
 issue 1186003
it_file 898763
Comment 4 Issue Tracker 2010-08-11 04:23:30 EDT
Event posted on 2010-07-26 19:55 CEST by asidorenko

File uploaded: nfs_create-request-linux.txt

This event sent from IssueTracker by rdassen 
 issue 1186003
it_file 898773
Comment 5 J.H.M. Dassen (Ray) 2010-08-11 04:27:22 EDT
The behaviour being requested is implemented in HP-UX. The attached packet traces illustrate the difference in behaviour between a current RHEL NFS client and an HP-UX one.

Note that there are some related comments in <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6894234> which touch upon this from a standards point of view.
Comment 6 Jeff Layton 2010-08-16 11:44:27 EDT
Hmm...the captures show NFSv3 packets, but the opensolaris bug you referenced was an NFSv4 problem. The NFSv4 problem was just a bug in Solaris that they eventually patched.

The only sane (and non-racy) way to handle the setgid bit on directories is to have the server handle it. It's also quite possible that the client won't have proper credentials to change the group ownership of the file after it has been created.

This really sounds like a server bug...
Comment 7 RHEL Product and Program Management 2010-08-16 11:55:14 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

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