explicación sobre la especificación POSIX de chown(1)

Question

La especificación POSIX para la chownutilidad.menciona en surazón fundamentalsecciónsobre la chown user:groupsintaxis (anteriormente chown user.group) (el énfasis es mío):

El método BSD 4.3 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 del 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 una cuestión de conveniencia. Ahora bien, lo anterior implica que hay cosas que puedes hacer con chown user:grouplas que no puedes.chgrp group; chown user

Ahora ese texto no tiene sentido para mí. En 4.3BSD, sólo el root podía cambiar el propietario de un archivo, 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, el texto anterior no tiene sentido para mí. Bien, si uno hace un 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 (sigue siendo el propietario del archivo) y chowndespués, y eso no es lo que el El texto de arriba dice exactamente.

No entiendo lo quey el propietario deseado no es miembro del grupo actualtiene que ver con el problema.

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

Answer 1

ElSubsistema Microsoft Interix Unix (ahora retirado)porque su kernel NT trata los permisos de usuarios y grupos de manera un poco diferente a como lo hacen otros:

La información de usuarios y grupos se almacena en elBase de datos de acceso de seguridad. Tanto los usuarios como los grupos se almacenan en la misma base de datos, pero los nombres de grupo y usuario 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 adecuada de Windows.(Administrador de usuarios, Usuarios y computadoras de Active Directory o Usuarios y grupos locales)o con el net usercomando Win32.(En el directorio se incluyen ejemplos de scripts de shell para crear y eliminar usuarios /usr/examples/admin).Los usuarios pueden pertenecer a muchos grupos.

Aquí estánalgunoextractos del manual más específicos:

En Windows, un usuario o un grupo pueden poseer un objeto. Esto es diferente de UNIX, en el que sólo 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 habrá 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). Una ACE incluye dos datos importantes: un SID de usuario o grupo y una descripción de cuánto acceso tiene el usuario o grupo individual a un objeto.

CHGRP

...Cambiar el ID de grupo del 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 propietario y de grupo son opcionales; sin embargo, se debe especificar uno. Si se especifica el operando de grupo, debe ir precedido de dos puntos (:).

El propietario se puede especificar mediante una ID de usuario numérica o un nombre de usuario. Si un nombre de usuario es también un ID de usuario numérico, el operando se utiliza como nombre de usuario. El grupo puede ser un ID de grupo numérico o un nombre de grupo. Si un nombre de grupo es también un ID de grupo numérico, el operando se utiliza como nombre de grupo.

Por razones de seguridad, la propiedad de un archivo sólo 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 pertenece a ese grupo, entonces es posible eliminar efectivamente chgrpese archivo 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 posibilidad de declararuser: y :groupnunca podrías lograr los mismos resultados que de otra manera.

Aquí hay un enlacehasta una mirada detallada a cómo Interix interactúa con las ACL de Windows, centrándose en cómo dicho conocimiento podría aplicarse a los sistemas de archivos Samba en otras variantes de Unix.

Aquí hay un enlacea un ahoraobsoletoDocumento de Solaris 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 la posibilidad de que se produzcan varios agujeros de seguridad. También abre la posibilidad de unaEl usuario cambia la propiedad de un archivo a otro usuario y no puede recuperar el archivo.volver sin intervención del usuario o del administrador del sistema.

Esta opción no invalida laConformidad POSIX. El solo hecho de que sea una opción la califica comoconforme:

Aunque todas las implementaciones que cumplen con POSIX.1-2008 admiten todas las funciones que se describen a continuación, es posible que hayaprocedimientos de configuración dependientes del sistema o dependientes del sistema de archivos que pueden eliminar o modificar cualquiera o todas estas características. Estas 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 usar las sysconf()funciones , o la pathconf()utilidad , para determinar qué características están presentes en el sistema en ese momento o para la ruta particular en cuestión.fpathconf()getconf

_POSIX_CHOWN_RESTRICTED

El uso de chown()está restringido a un proceso con privilegios apropiados y a cambiar el ID de grupo de un archivo solo al ID de grupo efectivo del proceso o a uno de sus ID de grupo suplementarios.

La chown()función del sistema, que es la llamada al sistema documentada realizada tanto por elchownychgrputilidades de shell - esespecificado para fallarpor numerosas razones. Entre ellos:

EACCES Se deniega el permiso de búsqueda en un componente del prefijo de ruta.

ELOOP Existe un bucle en los enlaces simbólicos encontrados durante la resolución del argumento de la ruta.

EPERM La ID de usuario efectiva no coincide con el propietario del archivo, o el proceso de llamada no tiene los privilegios adecuados y_POSIX_CHOWN_RESTRICTEDindica que dicho privilegio es necesario.

Sin embargo, el comportamiento de otorgar derechos de modificación de permisos a usuarios no root nunca ha sido exclusivo de Solaris. Haymuy bien- aunque algo anticuado - cobertura de permisos de archivos Unix enesta publicación en el foroen el que el autor afirma:

Originalmente, Unix permitía al propietario de un archivo regalar 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 pudiera deshacer 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 que un usuario podría tener en un sistema de archivos... Los usuarios traviesos podrían regalar archivos grandes para burlar las cuotas.

Hoy en día, no es fácil decir si un usuario no root puede almacenar chownun archivo. Muchas versiones de Unix permitenamboscomportamientos...

Otro buen -y más reciente-publicación en la lista de correocita esto y continúa:

El valor predeterminado en la mayoría de los sistemas operativos es chownestar restringido solo a root. Y existe consenso en que debería seguir así por consideraciones de seguridad. Si un usuario no root cambia el propietario de un archivo y cualquier bit de ejecución está activado, se deben borrar los bits SUIDy . SGIDEsto puede suceder o no 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.(eso sólo debería afectar el POSIX_CHOWN_RESTRICTEDcomportamiento). También existe la CAP_FOWNERcapacidad, que es un poco diferente en comportamiento.

Y comousted señala en 2003:

Tenga en cuenta que al menos en HPUX, puede cambiar el propietario de sus archivos(a rootpor ejemplo)incluso si no eres 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 los permisos de archivos, es concebible, como se menciona en elrazón fundamentalcitado en su pregunta, que un usuario puede tener chownun archivo que le pertenece para que sea propiedad de otro usuario. Si la propiedad del grupo del archivo y los chowngrupos del usuario ing no se alinean, entonces el usuario ya no podrá modificar ese archivo.

En este escenariochown entonces chgrpfallaría ya que el usuario ya no tendría permisos para alterar los permisos de ese archivo, mientras que chown user:group, siempre quegrupopertenece al usuario- tendría éxito.

HayprobablementeMuchas otras situaciones específicas que podrían resultar similares, que podrían incluir directoriopegajosoy/osetgidbits, sistemas de archivos y/o listas de control de acceso específicas de la implementación.este hiloes interesante, por ejemplo. Las innumerables permutaciones están mucho más allá de mi débil comprensión, razón por la cual esta respuesta está en wiki. Si estás leyendo esto, crees que vale la pena mejorarlo y crees que sabes cómo hacerlo.Por favor, hazlo.

También hay documentación extensa sobre los diversos efectos posibles de los permisos de archivos, el recorrido de árboles y los enlaces simbólicos que podrían provocar una falla similar con respecto a las aplicaciones -Recursivas chownaquí:

DeXRAT POSIXEncabezados de secciónTerceroyCuartos Dominios:

Generalmente, los usuarios que especifican la opción para atravesar la jerarquía de archivos desean operar en una única 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 de 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 comandochown -REl archivo del propietario se describe en los dominios tercero y cuarto.

...Existe un problema de seguridad al utilizar de forma predeterminada un paseo lógico. Históricamente, el mandochown -REl archivo de usuario ha sido seguro para el superusuario porquesetuidysetgidLos bits se perdieron cuando se cambió la propiedad del archivo. Si el recorrido fuera lógico, cambiar de propietario ya no sería seguro porque un usuario podría haber insertado un enlace simbólico que apunta a cualquier archivo del árbol. Nuevamente, esto requeriría agregar una opción a los comandos que atraviesan la jerarquía para no indirectamente 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 de sistemas, es preferible no tener diferentes valores predeterminados para diferentes clases de usuarios.

...

En BSD 4.3, chgrpdurante el recorrido del árbol se cambiaba el grupo del enlace simbólico, no el objetivo. Los enlaces simbólicos en BSD 4.4 no tenían propietario, grupo, modo u otros atributos de archivo del sistema UNIX estándar.

Y desde el POSIXchgrpEn la página propiamente dicha hay esto que apunta a una posible -Racción ecursiva incompleta, o al menos a lo queusadoser:

Las versiones System V y BSD utilizan diferentes códigos de estado de salida. Algunas implementaciones utilizaron el estado de salida como 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 del estándar optaron por enmascararlos especificando sólo 0 y >0 como valores de salida.

Answer 2

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

Supuesto 2: chown(file, -1, -1)tiene éxito.

Supuesto 3: las reglas para determinar si chownel proceso es exitoso no dependen del grupo al que pertenece actualmente el archivo.

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

No conozco ninguna variante de Unix que viole cualquiera de estas suposiciones, parecen bastante seguras.

Esta frase parece algo que alguien del comité dijo cuando estaba cansado después de horas de debatir cuántas opciones cabían en una psllamada (o que el secretario 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 el fundamento POSIX, así como la atomicidad (ah, si tan solo hubiera una única llamada para cambiar la propiedad y los permisos ).

---

Un caso en el que la suposición 3 podría ser errónea es en un sistema en el que un proceso puede obtener la capacidad de cambiar los propietarios del archivo, pero sólo si tiene 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 ni como root ni como usuario propietario del archivo, lo que podría hacer que el archivo esté fuera del límite para un archivo chown.

---

Para una llamada recursiva, hay casos extremos en los que una pasada completa chgrpseguida de una pasada completa chownpuede fallar cuando una sola pasada sería exitosa. Este no es un argumento muy convincente porque involucra directorios que el propietario no tiene permiso para recorrer, y una aplicación que quisiera protegerse contra todos esos casos necesitaría manipular los permisos de todos modos. No obstante, técnicamente cumple con la condición de este fundamento. Supongamos que el proceso en ejecución tiene un usuario efectivo alice, un grupo efectivo staffy la capacidad de cambiar los propietarios de los archivos arbitrariamente (no sólo para regalarlos; varias variantes de Unix tienen esa capacidad, aunque rara vez se concede a procesos que no son 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