chmod -x fails, apparently due to umask

Bug #67583 reported by Matt Zimmerman on 2006-10-22
6
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
Undecided
Matt Zimmerman

Bug Description

Test case:

mizar:[/tmp] cat chmod.sh
#!/bin/sh

umask 007
touch testfile
chmod 645 testfile
chmod -x testfile
ls -l testfile
mizar:[/tmp] ./chmod.sh
chmod: testfile: new permissions are rw-r--r-x, not rw-r--r--
-rw-r--r-x 1 mdz mdz 0 2006-10-22 08:05 testfile

and it's correct, the resulting permissions are not what they should be. strace shows, however, that it is not even attempting to set them correctly:

chmod("testfile", 0645) = 0

Matt Zimmerman (mdz) wrote :

(note that the same test succeeds with umask 022)

Kees Cook (kees) wrote :

The resulting file permissions are correct, according to the manpage:

If none of [the letters ‘ugoa’] are given, the effect is as if ‘a’ were given, but bits that are set in the umask are not affected.

At first I thought the exit code of 1 was a mistake, but it's not either. From the source:

/* If true, diagnose surprises from naive misuses like "chmod -r file".
   POSIX allows diagnostics here, as portable code is supposed to use
   "chmod -- -r file". */
static bool diagnose_surprises;

Changing the testcase to "chmod -- -x testfile" makes the exit code and warning go away.

Matt Zimmerman (mdz) wrote :

This is certainly an incompatible change in behaviour if so, though it wouldn't be the first.

Of course, if it's deciding that I'm on crack and should be ignored, surely it should never call chmod(2) in the first place?

Micah Cowan (micahcowan) wrote :

At any rate, the behavior is POSIX-mandated. POSIX also has the note: "Some implementations of chmod never used the process' umask when changing modes; systems conformant with this volume of IEEE Std 1003.1-2001 do so when who is not specified."

Are we okay to close this bug out, then? (I don't feel confident to reject Zimmerman bugs ;) )

Matt Zimmerman (mdz) wrote :

While this change is confusing, it's apparently conformant, and both chmod a-x and chmod -- -x do the expected thing. I'll retrain my fingers. (rejecting)

Changed in coreutils:
assignee: nobody → mdz
status: Unconfirmed → Rejected
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers