Bug 305341

Summary: fchmodat won't remove setgid/uid bits
Product: [Fedora] Fedora Reporter: Andrew Clayton <andrew>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7CC: jakub, twaugh
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: 2007-11-19 13:53:59 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 Andrew Clayton 2007-09-25 15:47:57 UTC 
Description of problem:

If you set the set[ug]id bits on a directory (or file). You can't take them off.

e.g in say /tmp

$ umask
0007

$ mkdir testdir
$ ls -ld testdir
drwxrwx---

$ chmod 2770 testdir
$ ls -ld testdir
drwxrws---

$ chmod 770 testdir
$ ls -ld testdir
drwxrws---

(Sticky bit still present)

Under FC6 the final chmod gives drwxrwx---

strace snippet of chmod 700 testdir shows 

fchmodat(AT_FDCWD, "testdir", 02770)    = 0

Version-Release number of selected component (if applicable):

glibc-2.6-4

How reproducible:

100%

Steps to Reproduce:

1. Create a directory
2. Set the group and/or user bits on the directory
3. Try to remove the sticky bits
  
Actual results:

Sticky bits remain

Expected results:

Sticky bits should be removed 

Additional info:

Tested on both x86 and x86_64
Comment 1 Jakub Jelinek 2007-09-25 18:46:41 UTC 
This has nothing to do with glibc, chmod program calls fchmodat with those
arguments:
ls -ld d; ltrace -e fchmodat chmod 770 d
drwxrws--- 2 jakub jakub 4096 2007-09-25 20:41 d
fchmodat(0xffffff9c, 0x60b0e0, 1528, 0, 1)                                     =
0
+++ exited (status 0) +++

1528 == 02770
Comment 2 Andrew Clayton 2007-11-16 23:03:05 UTC 
Problem remains in Fedora 8
Comment 3 Andrew Clayton 2007-11-19 13:53:59 UTC 
OK, turns out this isn;t a bug, just a change in behaviour. From the NEWS files.

chmod, install, and mkdir now preserve a directory's set-user-ID and
  set-group-ID bits unless you explicitly request otherwise.  E.g.,
  `chmod 755 DIR' and `chmod u=rwx,go=rx DIR' now preserve DIR's
  set-user-ID and set-group-ID bits instead of clearing them, and
  similarly for `mkdir -m 755 DIR' and `mkdir -m u=rwx,go=rx DIR'.  To
  clear the bits, mention them explicitly in a symbolic mode, e.g.,
  `mkdir -m u=rwx,go=rx,-s DIR'.  To set them, mention them explicitly
  in either a symbolic or a numeric mode, e.g., `mkdir -m 2755 DIR',
  `mkdir -m u=rwx,go=rx,g+s' DIR.  This change is for convenience on
  systems where these bits inherit from parents.  Unfortunately other
  operating systems are not consistent here, and portable scripts
  cannot assume the bits are set, cleared, or preserved, even when the
  bits are explicitly mentioned.  For example, OpenBSD 3.9 `mkdir -m
  777 D' preserves D's setgid bit but `chmod 777 D' clears it.
  Conversely, Solaris 10 `mkdir -m 777 D', `mkdir -m g-s D', and
  `chmod 0777 D' all preserve D's setgid bit, and you must use
  something like `chmod g-s D' to clear it.