El subsistema Microsoft Interix Unix (ahora retirado) para su núcleo NT se ocupó de manera un poco diferente con los permisos de usuarios y grupos que algunos otros:
La información de usuarios y grupos se almacena en la base de datos de Security Access . Tanto los usuarios como los grupos se almacenan en la misma base de datos, pero los nombres de grupos y usuarios deben ser únicos; ningún grupo puede tener un nombre de usuario y viceversa. (Esta base de datos reemplaza los archivos /etc/passwdy /etc/groupsen UNIX). Los usuarios y grupos se crean utilizando la metodología apropiada de Windows (Administrador de usuarios, Usuarios y equipos de Active Directory, o Usuarios y grupos locales) o con el net usercomando Win32 . (Los scripts de shell de ejemplo para crear y eliminar usuarios se incluyen en el directorio /usr/examples/admin). Los usuarios pueden pertenecer a muchos grupos.
Aquí hay algunos extractos manuales más específicos:
En Windows, un usuario o un grupo pueden poseer un objeto. Esto es diferente de UNIX, en el que solo un usuario posee un objeto.
Windows identifica a todos los usuarios y grupos internamente mediante un identificador de seguridad (SID) . Un algoritmo hash genera valores SID que son únicos; no hay dos usuarios o grupos que tengan el mismo SID.
Los usuarios y grupos que tienen permiso para acceder a un objeto se identifican por su SID. Todos los objetos que Windows puede proteger tienen una lista de control de acceso discrecional (DACL), que consta de entradas separadas llamadas entradas de control de acceso (ACE). Un ACE incluye dos piezas importantes de información: un SID de usuario o grupo, y una descripción de cuánto acceso tiene el usuario o grupo individual a un objeto.
CHGRP
... Cambie la ID de grupo para el archivo ... el usuario que invoca chgrp (1) debe pertenecer al grupo especificado y ser el propietario del archivo, o tener los privilegios adecuados.
CHOWN
... Los operandos del propietario y del grupo son opcionales; sin embargo, se debe especificar uno. Si se especifica el operando del grupo, debe ir precedido de dos puntos (:).
El propietario puede especificarse mediante un ID de usuario numérico o un nombre de usuario. Si un nombre de usuario también es un ID de usuario numérico, el operando se usa como nombre de usuario. El grupo puede ser un ID de grupo numérico o un nombre de grupo. Si un nombre de grupo también es una ID numérica de grupo, el operando se usa como nombre de grupo.
Por razones de seguridad, la propiedad de un archivo solo puede modificarse mediante un proceso con los privilegios adecuados.
Según lo leí, eso significa que si su cuenta de usuario pertenece a un grupo de Windows con privilegios suficientes para modificar los permisos de un archivo que es propiedad de ese grupo, entonces es posible que chgrpese archivo esté fuera del control de su cuenta de usuario. Esto equivale a un control menor del que podría tener con parámetros chownexplícitos user:group. En ese contexto sin la posibilidad de declarar user: y :group nunca podría lograr los mismos resultados que de otra manera.
Aquí hay un enlace a una visión detallada de cómo Interix interactúa con las ACL de Windows con un enfoque en cómo dicho conocimiento podría aplicarse a los sistemas de archivos Samba en otras variantes de Unix.
Aquí hay un enlace a un documento de Solaris ahora obsoleto que describe el sintonizable rstchownque ...
Indica si la semántica POSIX para la chown(2)llamada al sistema está vigente ...
Aparentemente, si el parámetro se establece en un valor de 0...
... desactivar la semántica POSIX abre el potencial para varios agujeros de seguridad. También abre la posibilidad de que un usuario cambie la propiedad de un archivo a otro usuario y no pueda recuperar el archivo sin la intervención del usuario o del administrador del sistema.
Dicha opción no invalida la conformidad POSIX de Solaris . Solo que sea una opción lo califica como conforme :
Aunque todas las implementaciones que cumplen con POSIX.1-2008 admiten todas las características descritas a continuación, puede haber procedimientos de configuración dependientes del sistema o del sistema de archivos que pueden eliminar o modificar
cualquiera o todas estas características. Dichas configuraciones no deben realizarse si se requiere un cumplimiento estricto.
Las siguientes constantes simbólicas se definirán con un valor distinto de -1. Si una constante se define con el valor cero, las aplicaciones deben utilizar los sysconf(), pathconf()o fpathconf()funciones, o la
getconfutilidad, para determinar qué características están presentes en el sistema en ese momento o para el nombre de ruta particular en cuestión.
_POSIX_CHOWN_RESTRICTED
El uso de chown()está restringido a un proceso con los privilegios apropiados y a cambiar la ID de grupo de un archivo solo a la ID de grupo efectiva del proceso o a una de sus ID de grupo suplementarias.
La chown()función del sistema - que es la llamada al sistema documentado hecho tanto por los chowny chgrpShell Utilidades - se especifica a fallar por numerosas razones. Entre ellos:
EACCES
El permiso de búsqueda se deniega en un componente del prefijo de ruta.
ELOOP
Existe un bucle en los enlaces simbólicos encontrados durante la resolución del argumento de ruta.
EPERM
El ID de usuario efectivo no coincide con el propietario del archivo, o el proceso de llamada no tiene los privilegios apropiados y _POSIX_CHOWN_RESTRICTED indica que se requiere dicho privilegio.
Sin embargo, el comportamiento de otorgar derechos de modificación de permisos a usuarios no root nunca ha sido exclusivo de Solaris. Existe una excelente cobertura, aunque algo anticuada, de los permisos de archivos Unix en esta publicación del foro en la que el autor declara:
Originalmente, Unix permitió que el propietario de un archivo regalara un archivo. El propietario de un archivo podría cambiar el propietario a otra persona. No había forma de que un usuario no root deshaga esta operación ... BSD [más tarde] eliminado chownde usuarios no root ... [en parte porque] ... implementó cuotas de disco que podrían limitar la cantidad de espacio en disco el usuario podría tener un sistema de archivos ... Los usuarios traviesos podrían regalar archivos grandes para escabullirse de las cuotas.
Hoy en día, no es fácil decir si un usuario no root puede hacer chownun archivo. Muchas versiones de Unix permiten ambos comportamientos ...
Otra buena - y más reciente - publicación de la lista de correo cita esto y continúa:
El valor predeterminado con la mayoría de los sistemas operativos es chownrestringirse solo a la raíz. Y existe un consenso de que debería permanecer así por razones de seguridad. Si un usuario no root cambia el propietario de un archivo y cualquier bit de ejecución está activado, los bits SUIDy SGIDdeben borrarse. Esto puede o no suceder con root.
Creo que el último párrafo lo dice muy bien.
Ese artículo también hace referencia CAP_CHOWNal control de esa instalación en Linux (que solo debería afectar el POSIX_CHOWN_RESTRICTEDcomportamiento) . También existe la CAP_FOWNERcapacidad, que es un poco diferente en el comportamiento.
Y como señalas en 2003 :
Tenga en cuenta que, al menos en HPUX, puede cambiar el propietario de sus archivos ( rootpor ejemplo) incluso si no es un usuario privilegiado ...
... que dependía de un setprivgroupparámetro de configuración .
En cualquier caso en el que un usuario no root pueda manipular permisos de archivos, es concebible, como se menciona en la justificación citada en su pregunta, que un usuario pueda tener chownun archivo que ese usuario posee para que sea propiedad de otro usuario. Si la propiedad del grupo del archivo y los chowngrupos del usuario no se alinean, el usuario ya no podrá modificar ese archivo.
En este escenario, chown entonces chgrp fallaría, ya que el usuario ya no tendría permisos para alterar los permisos de ese archivo, mientras que chown user:group, siempre y cuando el grupo esté entre los suyos, tendría éxito.
Hay probablemente muchas otras situaciones de nicho que pudieran derivarse de manera similar, que podrían incluir el directorio pegajosa y / o setgid pedazos, sistema de archivos y / o listas de control de acceso específicos de aplicación. Este hilo es interesante, por ejemplo. Las innumerables permutaciones están mucho más allá de mi débil comprensión, por lo que esta respuesta es engañosa. Si está leyendo esto, cree que vale la pena mejorarlo y cree que sabe cómo hacerlo, por favor hágalo .
También hay una extensa documentación sobre los diversos efectos posibles de los permisos de archivos, el recorrido del árbol y los enlaces simbólicos que podrían -Rprovocar un fallo similar con respecto a las chownaplicaciones ecursive aquí:
De los títulos de sección POSIX XRAT Terceros y Cuarto Dominios :
En general, los usuarios que especifican la opción para un recorrido de la jerarquía de archivos desean operar en una sola jerarquía física y, por lo tanto, se ignoran los enlaces simbólicos, que pueden hacer referencia a archivos fuera de la jerarquía. Por ejemplo, el archivo propietario chown es una operación diferente del mismo comando con la opción -R especificada. En este ejemplo, el comportamiento del comando chown owner filese describe aquí, mientras que el comportamiento del chown -Rarchivo propietario del comando se describe en los dominios tercero y cuarto.
... Hay un problema de seguridad con el valor predeterminado de una caminata lógica. Históricamente, el chown -Rarchivo de usuario de comando ha sido seguro para el superusuario porque los bits setuid y setgid se perdieron cuando se cambió la propiedad del archivo. Si la caminata fuera lógica, cambiar la propiedad ya no sería seguro porque un usuario podría haber insertado un enlace simbólico que apunta a cualquier archivo en el árbol. Nuevamente, esto requeriría la adición de una opción a los comandos que atraviesan la jerarquía para que no sean indirectos a través de los enlaces simbólicos, y los guiones históricos que realizan recorridos recursivos se convertirían instantáneamente en problemas de seguridad. Si bien esto es principalmente un problema para los administradores del sistema, es preferible no tener valores predeterminados diferentes para las diferentes clases de usuarios.
...
En 4.3 BSD, chgrpdurante el recorrido del árbol cambió el grupo del enlace simbólico, no el objetivo. Los enlaces simbólicos en 4.4 BSD no tenían el propietario, el grupo, el modo u otros atributos estándar del archivo del sistema UNIX.
Y desde la chgrppágina POSIX propiamente dicha, esto apunta a una posible -Racción ecursiva incompleta , o al menos a lo que solía ser:
Las versiones de System V y BSD usan diferentes códigos de estado de salida. Algunas implementaciones utilizaron el estado de salida como un recuento de la cantidad de errores que ocurrieron; Esta práctica es inviable ya que puede desbordar el rango de valores de estado de salida válidos. Los desarrolladores estándar optaron por enmascararlos especificando solo 0 y> 0 como valores de salida.