explicación sobre chown (1) especificaciones POSIX

La especificación POSIX para la chownutilidad menciona en su sección de justificación acerca de la chown user:groupsintaxis (anteriormente chown user.group) (énfasis mío):

El método 4.3 BSD para especificar tanto el propietario como el grupo se incluyó en este volumen de POSIX.1-2008 porque:

• Hay casos en los que no se pudo lograr la condición final deseada utilizando las utilidades chgrp y chown (que solo cambiaron la ID de usuario). (Si el propietario actual no es miembro del grupo deseado y el propietario deseado no es miembro del grupo actual, la función chown () podría fallar a menos que tanto el propietario como el grupo se cambien al mismo tiempo).

Pensé que la user:groupsintaxis era algo conveniente. Ahora lo anterior implica que hay cosas que puedes hacer con las chown user:groupque no puedeschgrp group; chown user

Ahora ese texto no tiene sentido para mí. En 4.3BSD, solo la raíz podría cambiar el archivo del propietario, por lo que en cualquier caso no hay restricciones en lo que puede hacer.

SysV y algunos otros sistemas permiten (o solían permitir) que el propietario de un archivo cambie el usuario y el grupo de un archivo a cualquier cosa, pero incluso en esos sistemas, ese texto anterior no tiene sentido para mí. OK, si uno hace una chown someone-else the-file, no puede hacerlo chgrp something-else the-filedespués porque ya no es el propietario del archivo, pero no hay nada que le impida hacer lo chgrpprimero (seguir siendo el propietario del archivo) y chowndespués, y eso no es lo que el El texto anterior es exactamente lo que dice.

No entiendo qué tiene que ver el problema con el propietario deseado y no es miembro del grupo actual .

Entonces, ¿cuáles son las condiciones para las cuales la función chown () podría fallar a menos que tanto el propietario como el grupo cambien al mismo tiempo y en qué sistema?

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.

Supuesto 1: las reglas para determinar si chowntiene éxito verifican el usuario objetivo y agrupan las partes de forma independiente, es decir, son de la forma user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Asunción 2: chown(file, -1, -1)tiene éxito.

Supuesto 3: las reglas para determinar si chowntiene éxito no dependen del grupo al que pertenece actualmente el archivo.

Corolario: si chown(file, uid, gid)tendría éxito, entonces también lo haría chown(file, -1, gid) && chown(file, uid, -1).

No sé de una variante de Unix que violaría cualquiera de estos supuestos, parecen bastante seguros.

Esta frase tiene el aspecto de algo que alguien en el comité dijo cuando estaban cansados ​​después de horas de debatir cuántas opciones cabían en la cabeza de una psllamada, o que la secretaria transcribió mal, y que nadie captó durante la revisión. Después de todo, hay otras buenas razones para permitir que el usuario y el grupo se cambien automáticamente, incluida la razón de rendimiento también citada en la justificación POSIX, así como la atomicidad (ah, si solo hubiera una sola llamada para cambiar la propiedad y los permisos )

Un caso en el que la suposición 3 podría estar equivocada es en un sistema en el que un proceso puede obtener la capacidad de cambiar los propietarios de los archivos, pero solo si tienen permiso de escritura en el archivo. Si bien es algo realista, no conozco ningún sistema en el que este sea el caso. Luego, chgrpa un grupo de un proceso que no se ejecuta como root ni como el usuario propietario del archivo podría hacer que el archivo esté fuera del límite para más adelante chown.

Para una llamada recursiva, hay casos extremos en los que un pase completo chgrpseguido de un pase completo chownpuede fallar cuando un solo pase tiene éxito. Este no es un argumento muy convincente porque involucra directorios que el propietario no tiene permiso para recorrer, y una aplicación que quisiera proteger contra todos estos casos necesitaría jugar con los permisos de todos modos. No obstante, técnicamente cumple con la condición de esta justificación. Suponga que el proceso en ejecución tiene un usuario efectivo alice, un grupo efectivo staffy la capacidad de cambiar los propietarios de archivos de manera arbitraria (no solo para regalarlos; varias variantes de Unix tienen esa capacidad, aunque rara vez se otorga a procesos no root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied