chown elimina el bit setuid: ¿error o característica?

14

Pasos para reproducir:

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

Probado con Debian Squeeze y Ubuntu 12.04

permissions users chown

— Germar
fuente

¿Eso también lo hace en Fedora 17?

— BenjiWiebe

1

característica

— mikeserv

17

No es un error de acuerdo con la documentación del chown:

PS 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.

— jlliagre
fuente

Gracias jlliagre. No lo sabía info coreutilsantes. Solo leí la página de manual y busqué en la web.

— Germar

12

Esto es por diseño, y es un comportamiento estándar. Citando el estándar POSIX :

A menos que chown sea invocado por un proceso con los privilegios apropiados, los bits set-user-ID y set-group-ID de un archivo regular se borrarán una vez que se complete con éxito; los bits set-user-ID y set-group-ID de otros tipos de archivos pueden borrarse.

( ses setuid (o setgid en la columna del grupo), no pegajoso, por cierto).

Este comportamiento sigue al de la llamada del sistema subyacente (excepto que en algunos sistemas, los bits setxid solo se borran para archivos ejecutables).

La razón para eliminar el bit setuid es que cambiar el propietario también cambia qué usuario será la ID de usuario efectiva del proceso. En particular, en sistemas donde un usuario puede regalar un archivo, cp /bin/sh foo; chmod u+s foo; chown joe foocrearía un ejecutable setuid que pertenece a Joe, un agujero de seguridad gigante.

— Gilles 'SO- deja de ser malvado'
fuente

¡Votación a favor de la pelea! ¡SUID / SGID no son el bit "pegajoso"!

— Jim Dennis

Gran punto sobre las implicaciones de seguridad de preservar SUID / SGID. El comportamiento me molestó hasta que leí esa oración. Sin embargo, agregaría que nunca he visto que Chown no borre los bits, incluso cuando se ejecuta como root. Tengo curiosidad por saber qué "privilegios apropiados" implicarían.

— vastlysuperiorman

1

@vastlysuperiorman En una plataforma clásica de Unix, "privilegios apropiados" significa ID de usuario 0. Pero POSIX permite que los sistemas definan sus propias políticas de seguridad. Por ejemplo, para muchas operaciones en Linux, los "privilegios apropiados" se implementan como una capacidad (que solo la raíz obtiene por defecto). En este caso particular, suprime los bits setxid en chown independientemente de los privilegios, como la mayoría, si no todas, las variantes de Unix. Pero una capa POSIX en Windows podría funcionar de manera diferente.

— Gilles 'SO- deja de ser malvado'