retitle coreutils: chown/chgrp invalidly reset suid/sgid tag 665451 + unreproducible wontfix severity 665451 normal thanks
Yoric Kotchukov wrote: > chown/chgrp illegally reset suid/sgid. I think this is critical, as > it is often used in [post/pre]install scripts, see Bug #664206. It can only be an invalid operation. It isn't "illegal". No laws are involved. > globus@aspera:~/mia/tmp$ ls -l > -rwxr-sr-x 1 globus globus 12 Мар 24 17:12 testp > > globus@aspera:~/mia/tmp$ chown globus:tempo testp > Debian Release: wheezy/sid > Architecture: i386 (x86_64) > Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) I cannot reproduce this behavior. This chown action should produce an error message. By default on BSD-like systems such as Debian GNU/Linux chown is only allowed by root. You should be seeing this error message: chown: changing ownership of `testp': Operation not permitted Only on System V like systems is chown by non-root allowed by default. This FAQ reference explains the issue in more detail: http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f > globus@aspera:~/mia/tmp$ ls -l testp > -rwxr-xr-x 1 globus tempo 12 Мар 24 17:12 testp Yes. This is documented in the chown manual this way: The `chown' command sometimes clears the set-user-ID or set-group-ID permission bits. This behavior depends on the policy and functionality of the underlying `chown' system call, which may make system-dependent file mode modifications outside the control of the `chown' command. For example, the `chown' command might not affect those bits when invoked by a user with appropriate privileges, or when the bits signify some function other than executable permission (e.g., mandatory locking). When in doubt, check the underlying system behavior. Therefore I do not consider this a bug in coreutils but rather a policy decision made by the underlying host operating system kernel. Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
