Description of problem: On RHEL5, chown 0 <file> does not preserve the setuid bit of <file>. This behavior is different than RHEL4, which preserves the setuid. Is this change in /bin/chown's behavior intentional? Version-Release number of selected component (if applicable): CentOS release 5.2 (Final) coreutils-5.97-14.el5 How reproducible: Always Steps to Reproduce: [root@flatline ~]# touch test [root@flatline ~]# chmod u+s test [root@flatline ~]# ls -l test -rwSr--r-- 1 root root 0 Feb 26 04:11 test [root@flatline ~]# chown 0 test [root@flatline ~]# ls -l test -rw-r--r-- 1 root root 0 Feb 26 04:11 test Expected results: The setuid bit is preserved when running the above steps on RHEL4 Additional info: http://lkml.indiana.edu/hypermail/linux/kernel/9706.0/0068.html
Thanks for report, I agree it is somewhat tricky behaviour but as said in upstream NEWS 5.3.0 (between RHEL-4 and RHEL-5): "Do not optimize away the chown() system call when the file's owner and group already have the desired value. This optimization was incorrect, as it failed to update the last-changed time and reset special permission bits, as POSIX requires." Posix formulation (http://www.opengroup.org/onlinepubs/000095399/utilities/chown.html): "Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared." As no change is succesful completition it looks like POSIX requires it. Therefore I would call it NOTABUG and intentional change as we should be as POSIX compliant as possible. Closing NOTABUG.
You missed the first part of that clause though, Ondrej: "Unless chown is invoked by a process with appropriate privileges" I believe root has appropriate privileges. I suspect that clause is not in support of the change made in the 2.6 kernel. There may be other clauses, but not this one. I believe this is still a bug.