¿Por qué se ignora setuid en los directorios?

En los sistemas Linux, puede chmod u+s $some_directoryhacerlo con éxito , pero en lugar de forzar la propiedad de nuevos subdirectorios y archivos para ser el propietario del directorio que los contiene (y establecer subdirectorios u+stambién) como podría esperar, el sistema simplemente ignora el bit setuid. Los subdirectorios y archivos continúan heredando los UID de sus procesos de creación, y los subdirectorios no están configurados de manera predeterminada.

¿Por qué se ignora setuid en los directorios y cómo puedo hacer que el sistema lo reconozca?

Recuerde que los bits setuid y setgid se inventaron para un propósito completamente diferente: hacer que un ejecutable se ejecute con el uid o gid de su propietario, en lugar del uid o gid del usuario que ejecuta el archivo. Cualquier otro uso es solo una característica adicional.

Estos bits no tienen función en archivos ordinarios que no son ejecutables. (Y también scripts de shell en algunas distribuciones, debido a problemas de seguridad). Originalmente, tampoco tenían función para directorios. Obviamente, alguien decidió que sería genial tomar el setgid no utilizado en los directorios y usarlo para garantizar la coherencia de la propiedad del grupo. Después de todo, si está jugando con la propiedad del grupo, es porque más de una persona está trabajando con el archivo, y probablemente tenga sentido que todos los archivos de un directorio dado pertenezcan al mismo grupo, sin importar quién los haya creado. Se eliminan las molestias debido a que alguien se olvida de ejecutar newgrp.

Entonces, ¿por qué no implementar la misma característica para setuid y el archivo uid? Bueno, uid es mucho más básico que gid. Si implementa esto, a menudo un archivo no pertenecerá al usuario que lo creó. Presumiblemente, el usuario aún puede modificar el archivo (suponiendo que la umask es algo sensato), pero no puede cambiar los bits de permiso. Es difícil ver la utilidad de eso.

Creo que la respuesta a esta pregunta tiene que ver con los problemas de seguridad de "entrega de archivos" que han resultado en la mayoría de los sistemas operativos modernos tipo Unix que no permiten la "entrega de archivos". "Entrega de archivos" es cuando un usuario que no es superusuario cambia la propiedad de un archivo a otra persona que no sea ese usuario. Esta capacidad ofrece muchas oportunidades para la travesura.

Dado que no se permiten sorteos de archivos, setuid en los directorios, que realizarían la misma función en otra forma, no está permitido o ignorado si se establece.

En cuanto a cambiar el comportamiento, tendría que modificar las bibliotecas y utilidades del sistema operativo.

Un muy buen caso de uso para implementarlo es este:

Digamos que tiene un servidor multisitio con 3 sitios seguros. Tienes 3 grupos creados, uno para cada uno de los diferentes mantenedores de sitios. Todos los archivos en todos los sitios deben ser propiedad del usuario de apache para que apache pueda leerlos y escribirles (drupal / wordpress, etc.).

Si el setuid funcionara como el bit setgid para los permisos de directorios, se vería así:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

De esta forma, cada grupo de mantenedores tenía acceso para ver y tocar solo su contenido, pero el usuario del servidor web apache podía servir todo el contenido y no era necesario que los usuarios se preocuparan por cambiar la propiedad de los archivos cargados.

Otro caso de uso es para ftp / http anónimo o incluso cargas sftp / ssh. El grupo y el GID en el directorio de carga serían root, al igual que el propietario y el UID. Los otros permisos serían -wx. Esto permitiría a todos ESCRIBIR el acceso al directorio de carga, pero no podrían leer nada una vez que se cargó y la raíz sería propietaria de todos los archivos recién creados.

Por lo tanto, hay dos casos de uso perfectamente buenos y válidos para habilitar la funcionalidad UID en los directorios para que coincida con el bit GID.

Steven Mercurio

Un poco tarde para la fiesta, pero en caso de que los futuros lectores se encuentren con esto;) Como lo han dicho otros, en un sistema de archivos OS-X estándar se ignora el setUID para directorios, y no parece haber una forma fácil de evitar esto ( mount -o.... o lo que no). Como a menudo, la página de manual en realidad no cumple con el comportamiento de OS-X, literalmente dice:

4000 (el bit set-user-ID-on-execute) [...] Los directorios con el bit set-user-id set obligarán a que todos los archivos y subdirectorios creados en ellos sean propiedad del propietario del directorio y no de el uid del proceso de creación [...]

pero también enumera la posibilidad de lograr el mismo efecto sin renunciar a la propiedad original. Linux usa '[g /] setfacls' para efectos similares (son permisos que no son realmente visibles a primera vista, por lo que a veces puede ser una molestia).

En cuanto al 'cómo puedo lograr efectos similares', lea la página de manual completa y juegue con:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

puedes consultar a través de

ls -le

si todo se ve bien Otras opciones incluyen insertar reglas en posiciones específicas, eliminar o reemplazar reglas específicas. Las dos opciones notables aquí son " file_inherity directory_inherit" que permiten que las reglas se adjunten a un nuevo directorio / archivo.

Realmente no me gusta usar setUID, pero setGID es muy útil en servidores de archivos donde simplemente configurar el grupo 'principal' no funciona o los clientes tienen máscaras de archivos que no permiten la escritura grupal. Eso sería resuelto por:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Bueno, debe respetar el estándar. Puedo pensar en bastantes escenarios con sftp-only que me ahorraría muchos problemas, tanto con acl como con el conjunto de máscara de acl que hace sshd, y el reinicio que debo hacer a esa máscara.

La seguridad por defecto es bastante útil, pero si no la convierte en una opción, simplemente está creando una pesadilla.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

De cualquier manera, es como lo hace Linux ahora, así que solo use acl para solucionarlos.

De acuerdo con http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories, el bit setuid se ignora para los directorios en los sistemas UNIX y Linux. Sin embargo, es posible hacer que actúe como espera en FreeBSD.