Red Hat Bugzilla – Full Text Bug Listing
|Summary:||chmod not processing numeric mode commands correctly for directories|
|Product:||[Fedora] Fedora||Reporter:||Steve Bryant <stephenbryant>|
|Component:||coreutils||Assignee:||Tim Waugh <twaugh>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-06-10 05:32:45 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Steve Bryant 2007-06-09 06:51:39 EDT
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` coreutils-6.9-2.fc7 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 testdir" 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 11:40:20 EDT
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 02:41:15 EDT
*** Bug 244422 has been marked as a duplicate of this bug. ***
Comment 3 Steve Bryant 2007-06-18 04:13:48 EDT
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 09:40:53 EDT
+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 10:02:31 EDT
I know adapting to this type of change can be painful. Please see the discussion here: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/7610 If you can add arguments not addressed in that thread, please let us know.
Comment 6 Zing 2007-06-18 10:58:25 EDT
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.