chown remove o bit setuid: bug ou recurso?

Question

Etapas para reproduzir:

germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov  2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov  2 20:11 test

Testado com o Debian squeeze e o Ubuntu 12.04

    

Answer 1

Não é um bug de acordo com a documentação do chown:

$ info coreutils 'chown invocation'

   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.

    

Answer 2

Isso é por design e seu comportamento padrão. Citando o padrão POSIX :

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.

( s é setuid (ou setgid na coluna do grupo), não pegajoso, a propósito.)

Este comportamento segue o da chamada de sistema subjacente (exceto que em alguns sistemas, o bits setxid são limpos apenas para arquivos executáveis).

O motivo para remover o bit setuid é que alterar o proprietário também altera qual usuário será o ID do usuário efetivo do processo. Em particular, em sistemas em que um usuário pode distribuir um arquivo, cp /bin/sh foo; chmod u+s foo; chown joe foo criaria um executável setuid pertencente a joe, uma brecha de segurança gigante.