Bug 623054 - [RFE] SGID processing by NFS-client
Summary: [RFE] SGID processing by NFS-client
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 5.7
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jeff Layton
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Keywords: FutureFeature, Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-11 08:14 UTC by Issue Tracker
Modified: 2018-10-27 12:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-16 15:55:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Issue Tracker 2010-08-11 08:14:04 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2010-08-11 08:14:06 UTC
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 08:23:26 UTC
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 08:23:30 UTC
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 08:27:22 UTC
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 15:44:27 UTC
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 15:55:14 UTC
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.