martin f krafft <[EMAIL PROTECTED]> wrote:
> Package: coreutils
> Version: 5.2.1-2
>
> /bin/chgrp, when invoked on a SETUID file, drops the SETUID bit:
>
> wing:~# ls -l /bin/su
> -rwxr-xr-x 1 root root 23416 2005-03-15 13:59 /bin/su*
> wing:~# chmod 4754 /bin/su
> chmod 4754 /bin/su
> wing:~# ls -l /bin/su
> -rwsr-xr-- 1 root root 23416 2005-03-15 13:59 /bin/su*
> wing:~# chgrp wheel /bin/su
> chgrp wheel /bin/su
> wing:~# ls -l /bin/su
> -rwxr-xr-- 1 root wheel 23416 2005-03-15 13:59 /bin/su*
Thanks for the report, but is that really a bug?
I.e., is it contrary to POSIX?
The standard says that chgrp
shall perform actions equivalent to the chown() function
with the following arguments:
* The file operand shall be used as the path argument.
* The user ID of the file shall be used as the owner argument.
* The specified group ID shall be used as the group argument. Unless
chgrp 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.
Then, consider this comment from chown-core.c:
(chgrp.c does most of its work via chown-core.c's chown_files function)
/* On some systems (e.g., Linux-2.4.x),
the chown function resets the `special' permission bits.
Do *not* restore those bits; doing so would open a window in
which a malicious user, M, could subvert a chown command run
by some other user and operating on files in a directory
where M has write access. */
The chgrp and chown programs used to restore those bits if/when the
chown function reset them, but that opened a nasty security hole.
Jim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
