Recuerde que los bits setuid y setgid se inventaron con 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 función adicional.
Estos bits no tienen ninguna 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 ninguna función para los directorios. Obviamente, alguien decidió que sería genial tomar el setgid no utilizado en los directorios y usarlo para hacer cumplir 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 en un directorio determinado pertenezcan al mismo grupo, sin importar quién los haya creado. Se eliminan las molestias debidas a que alguien se olvida de ejecutar newgrp.
Entonces, ¿por qué no implementar la misma función 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 umask sea 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 del "regalo de archivos" que ha dado como resultado que la mayoría de los sistemas operativos modernos similares a Unix no permitan el "regalo de archivos". El "regalo de archivo" es cuando un usuario que no es superusuario cambia la propiedad de un archivo a otra persona que no sea ese usuario. Esta capacidad brinda muchas oportunidades para hacer travesuras.
Dado que no se permite la entrega de archivos, setuid en directorios, que realizaría la misma función en otra forma, no se permite o se ignora 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 escribirlos (drupal/wordpress, etc.).
Si el setuid pero 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 manera, cada grupo de mantenedores tenía acceso para ver y tocar solo su contenido, pero el usuario apache del servidor web podía servir todo el contenido y no había necesidad de que los usuarios se preocuparan por cambiar la propiedad de los archivos cargados.
Otro caso de uso es para cargas ftp/http anónimas o incluso sftp/ssh. El grupo y el GID en el directorio de carga serían raíz, al igual que el propietario y el UID. Los otros permisos serían -wx . Esto permitiría que todos tuvieran acceso de ESCRITURA al directorio de carga, pero no podrían leer nada una vez que se cargara 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