From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 Description of problem: chmod = operator uses all four bits from {u,g,o} when modifying permissions, whereas it should probably operate only on the rwx bits, and not the setuid/setgid/sticky bits, since these don't have commensurable meanings (certainly not for sticky, and arguably for setuid/setgid). Version-Release number of selected component (if applicable): chmod (GNU fileutils) 4.0.36 How reproducible: Always Steps to Reproduce: 1. mkdir /tmp/foo.d 2. chmod 2775 /tmp/foo.d 3. chmod g=o /tmp/foo.d 4. ls -ld /tmp/foo.d Actual Results: drwxr-xr-x 2 dupuy sysman 1024 Apr 2 11:14 /tmp/foo.d Expected Results: drwxr-sr-x 2 dupuy sysman 1024 Apr 2 11:14 /tmp/foo.d Additional info: Not sure what, if anything, POSIX.2 specifies about the behavior of chmod g=o. If they require this pretty stupid and unexpected behavior, I guess you have to implement it as such. It's quite possible they have nothing to say on the subject, though, since g=o type operations may be an extension of the POSIX.2 spec.
Single Unix states If the calling process does not have appropriate privileges, and if the group ID of the file does not match the effective group ID or one of the supplementary group IDs and if the file is a regular file, bit S_ISGID (set-group-ID on execution) in the file's mode will be cleared upon successful return from chmod(). Additional implementation-dependent restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored.
This is fixed in fileutils 4.1 (RH 7.2 and later)