Bug 243517 - chmod not processing numeric mode commands correctly for directories
Summary: chmod not processing numeric mode commands correctly for directories
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
(Show other bugs)
Version: 7
Hardware: i686 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
: 244422 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-09 10:51 UTC by Steve Bryant
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-10 09:32:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Steve Bryant 2007-06-09 10:51:39 UTC
Description of problem:
chmod cannot turn off  directory "set user ID" and "set group ID" bits using
numeric mode (octal permissions).

Version-Release number of selected component (if applicable):
# rpm -qf `which chmod`

How reproducible:

Steps to Reproduce:
1. Enter command "mkdir testdir", then "ls -ld testdir"
   "drwxr-xr-x 2 root root 1024 2007-06-09 11:31 testdir" is displayed.

2. Enter command "chmod 7777 testdir", then "ls -ld testdir"
   "drwsrwsrwt 2 root root 1024 2007-06-09 11:31 testdir" is displayed.

3. Enter command "chmod 777 testdir" (or "chmod 0777 testdir"), then "ls -ld

Actual results:
   "drwsrwsrwx 2 root root 1024 2007-06-09 11:31 testdir" is displayed (only the
"sticky bit" is turned off).

Expected results:
   "drwxrwxrwx 2 root root 1024 2007-06-09 11:31 testdir" should be displayed
("set user ID", "set group ID" and "sticky bit" all turned off).

Additional info:
Tested on ext3 partitions, both under LVM and not.  Regular files have their
modes altered as expected

Comment 1 Jim Meyering 2007-06-09 15:40:20 UTC
Thanks for the report, but the behavior you're seeing is due to a deliberate
change in a murky area (not specified by POSIX, and not portable in practice).
Here's the NEWS item from coreutils-6.0.  The part about clearing bits at the
end of the paragraph below is what's relevant to your report:

  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.

Comment 2 Jim Meyering 2007-06-18 06:41:15 UTC
*** Bug 244422 has been marked as a duplicate of this bug. ***

Comment 3 Steve Bryant 2007-06-18 08:13:48 UTC
I would count "chmod 0777" as EXPLICITLY requesting the reset of all special
bits even if "chmod 777" did not reset them.

This seems only to add to the confusion and inconsistency over use of octal
modes.  It always was understood that specifying octal values for file modes
"blatted" the  original permissions, whatever they were.  Now this is not so ...
for directories.

Comment 4 Zing 2007-06-18 13:40:53 UTC
+1 to Comment #3.  Please, consider 0xxx as explicitly clearing the bits.  I'm
trying not to blow my fuse.  Meet me halfway!  (i'll just be half angry!)

Comment 5 Jim Meyering 2007-06-18 14:02:31 UTC
I know adapting to this type of change can be painful.  Please see the
discussion here:


If you can add arguments not addressed in that thread, please let us know.

Comment 6 Zing 2007-06-18 14:58:25 UTC
Hi Jim, I just don't have the time and energy and experience to argue this.

My only last additional comment is to please make sure that RHEL Engineering
clears this.  The absolute worst situation for me is if Fedora and RHEL diverge
in semantics.

Thank you for your work.

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