Bug 485099 - Inconsistent behaviour in stripping SUID/SGID flags when chmod/chgrp directories
Inconsistent behaviour in stripping SUID/SGID flags when chmod/chgrp directories
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ric Wheeler
Red Hat Kernel QE team
:
Depends On:
Blocks: 533192 487108 526775
  Show dependency treegraph
 
Reported: 2009-02-11 11:10 EST by Sachin Prabhu
Modified: 2014-06-09 07:17 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 487108 (view as bug list)
Environment:
Last Closed: 2010-03-30 03:39:08 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)
Proposed patch (1.31 KB, patch)
2009-06-01 11:30 EDT, Peter Staubach
no flags Details | Diff

  None (edit)
Description Sachin Prabhu 2009-02-11 11:10:51 EST
There is an inconsistency seen in the behaviour of ext3 and nfs  when changing owner or group of a directory. If the directory has SUID/SGID flags set, the flags are maintained on ext3 however they are stripped on nfs.

Reproducer:

ext3:

file
# touch xyz; chmod u+s xyz; ls -l xyz; chown bin xyz; ls -l xyz
-rwSr--r--  1 root root 0 Feb 10 16:25 xyz
-rw-r--r--  1 bin root 0 Feb 10 16:25 xyz

directory
mkdir abc; chmod u+s abc; ls -ld abc; chown bin abc; ls -ld abc
drwsr-xr-x  2 root root 4096 Feb 10 16:23 abc
drwsr-xr-x  2 bin root 4096 Feb 10 16:23 abc


nfs:

file
# touch xyz; chmod u+s xyz; ls -l xyz; chown bin xyz; ls -l xyz
-rwSr--r--  1 root root 0 Feb 10 16:25 xyz
-rw-r--r--  1 bin root 0 Feb 10 16:25 xyz

directory
# mkdir abc; chmod u+s abc; ls -ld abc; chown bin abc; ls -ld abc
drwsr-xr-x  2 root root 4096 Feb 10 16:23 abc
drwxr-xr-x  2 bin root 4096 Feb 10 16:23 abc

Check the SUID/SGID flags on the directory before and after the chown operation for directories. The flags are stripped under nfs but not under ext3. The behaviour for operations on the file are consistent.
Comment 1 Sachin Prabhu 2009-02-11 11:13:15 EST
The behaviour as it stands does not appear to violate POSIX. See:

http://www.opengroup.org/onlinepubs/7990989775/xcu/chgrp.html
http://www.opengroup.org/onlinepubs/7990989775/xsh/chown.html

"Unless chgrp is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file will be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared."

"If the path argument refers to a regular file, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode are cleared upon successful return from chown(), unless the call is made by a process with appropriate privileges, in which case it is implementation-dependent whether these bits are altered. If chown() is successfully invoked on a file that is not a regular file, these bits may be cleared. These bits are defined in <sys/stat.h>."

So POSIX does not require a particular behaviour even if the process has "appropriate privileges" (which itself is not defined) but leaves this to be defined by the implementation. However the actions performed are inconsistent when comparing ext3 and nfs.
Comment 2 Jeff Layton 2009-02-11 11:34:34 EST
Yes, even if we don't violate the letter of the spec it would be good to have the kernel behave consistently here. The point is that chown_common (which is what chown() calls from userspace pass through) only tries to kill the setuid/gid bits if it's not a directory.

I think we should add a clause to nfsd_setattr that just does the bit-clearing if !S_ISDIR.

This will need to go upstream first, but it may be a little while before I can get to it. Shouldn't be too hard a patch if someone else wants to do the legwork for it though.
Comment 3 Sachin Prabhu 2009-02-23 11:39:26 EST
http://article.gmane.org/gmane.linux.nfs/24652
Comment 4 Sachin Prabhu 2009-03-19 06:09:21 EDT
The proposed patch has been committed upstream in the Bruce Fields's git repo and will be included in 2.6.30 upstream tree.

http://git.linux-nfs.org/?p=bfields/linux.git;a=commit;h=f24b623ed07342f7b227bf65a190c33514cec8a4
Comment 7 Peter Staubach 2009-06-01 11:30:11 EDT
Created attachment 346092 [details]
Proposed patch
Comment 9 RHEL Product and Program Management 2009-09-25 13:37:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Don Zickus 2009-10-06 15:36:28 EDT
in kernel-2.6.18-168.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 12 Chris Ward 2010-02-11 05:07:14 EST
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
Comment 17 errata-xmlrpc 2010-03-30 03:39:08 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html

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