¿Por qué no puede un usuario normal `chown` un archivo?

¿Por qué el chowncomando es solo de raíz? ¿Por qué los usuarios no root pueden usar chown para regalar los archivos que poseen?

permissions not-root-user chown

— flema
fuente

No puedo entender su comando chown pregunta puede ser utilizado por el usuario no raíz también

— harish.venkat

Tal vez lo puse mal. Bueno, la pregunta exacta de mi Proffesor fue: "¿Por qué el movimiento de los derechos de un usuario normal no está permitido en los sistemas UNIX?" ...

— phleg

Creo que la verdadera pregunta es: ¿por qué los usuarios no root pueden usar chownpara regalar archivos que poseen? (He visto sistemas en los que, dependiendo de la configuración del sistema de archivos, se puede.)

— Keith Thompson

relacionado: askubuntu.com/questions/95985/…

— Ciro Santilli 新疆改造中心法轮功六四事件

Respuestas:

La mayoría de los sistemas Unix evitan que los usuarios "regalen" archivos, es decir, los usuarios solo pueden ejecutarse chownsi tienen los privilegios de usuario y grupo objetivo. Dado que el uso chownrequiere ser propietario del archivo o ser root (los usuarios nunca pueden apropiarse de los archivos de otros usuarios), solo el root puede ejecutarse chownpara cambiar el propietario de un archivo a otro usuario.

La razón de esta restricción es que regalar un archivo a otro usuario puede permitir que sucedan cosas malas en situaciones poco comunes pero importantes. Por ejemplo:

Si un sistema tiene cuotas de disco habilitadas, Alice podría crear un archivo de escritura mundial en un directorio accesible solo para ella (para que nadie más pueda acceder a ese archivo de escritura mundial), y luego ejecutarlo chownpara que ese archivo sea propiedad de otro usuario Bill. El archivo entonces contaría bajo la cuota de disco de Bill, aunque solo Alice puede usar el archivo.
Si Alice le regala un archivo a Bill, no hay rastro de que Bill no haya creado ese archivo. Esto puede ser un problema si el archivo contiene datos ilegales o comprometedores.
Algunos programas requieren que su archivo de entrada pertenezca a un usuario en particular para autenticar una solicitud (por ejemplo, el archivo contiene algunas instrucciones que el programa realizará en nombre de ese usuario). Por lo general, este no es un diseño seguro, porque incluso si Bill creó un archivo que contiene instrucciones sintácticamente correctas, es posible que no haya tenido la intención de ejecutarlas en este momento en particular. Sin embargo, permitir que Alice cree un archivo con contenido arbitrario y lo tome como entrada de Bill solo puede empeorar las cosas.

— Gilles 'SO- deja de ser malvado'
fuente

En un trabajo anterior, construí un sistema de software que dependía de la incapacidad de regalar archivos. Usó la propiedad del archivo para verificar que un usuario en particular haya enviado una solicitud. Verificó, durante la instalación, si se permitía regalar archivos y, de ser así, se negó a continuar.

— Keith Thompson

Otro problema más crítico es que un usuario podría copiarlo /bin/bash, configurarlo y luego chownenviarlo a quien quiera. Ahora tienen acceso de shell como esa persona.

— Patrick

@Patrick chownsiempre borra los bits setuid y setgid.

— Gilles 'SO- deja de ser malvado'

@Gilles y por una buena razón ... si pudieras copiar un binario de shell en algún lugar puedes acceder a él, establece los bits setuid / gid en él y conviértelo en root (o en cualquier orden que te dé 6755/0: 0 permisos) / propiedad) puede obtener root en ese sistema. Oh, perdí el comentario de Patrick, exactamente.

— Hanetzer

Ok, pero si soy dueño del directorio ( drwxr-xr-x ring0 ring0 .) en el que la raíz tiene un archivo normal ( -rw-r--r-- root root file), ¿por qué no puedo hacerlo chown ring0 fileya que de todos modos está permitido hacerlo, como ring0, cp file x ; rm file ; mv x file(y algunos opcionales touch sometime file...)?

— Anillo Ø

En Linux, necesita la capacidad CAP_CHOWN para hacer chown. la raíz se le otorga tal. Consulte: http://vouters.dyndns.org/tima/Linux-OpenVMS-C-Implementing_chown.html para obtener explicaciones. Si tiene la intención de dar la capacidad CAP_CHOWN, cree su código con libcap-ng o libcap como lo demuestra: http://vouters.dyndns.org/tima/Linux-PAM-C-Pluggable_Authentication_Modules_programming_example.html donde tiene que reemplazar simplemente CAP_AUDIT_WRITE con CAP_CHOWN.

— usuario1910461
fuente

+1 para usted no tiene que ser root. Porque ya no tienes que ser root.

— ctrl-alt-delor

A veces, ni siquiera necesita CAP_CHOWN: unix.stackexchange.com/questions/399975/… De mi lectura de la fuente del núcleo, cada implementación del sistema de archivos tiene la tarea de verificar los permisos para Chown. Y parece que con NFS, los permisos se verifican en el lado del servidor. Y si el servidor es ... extraño ... entonces es posible.

— Mike S

Puede iniciar el comando, pero no funcionará si no es root. Es fácil: imagine un usuario que pueda cambiar un software a usuario root. Puede agregar el bit setuid y, ¡voilà, el tipo es root! Entonces, el uso puede agregar el bit con chmod, pero no hay posibilidad de cambiar el propietario de los archivos.

— Dom
fuente

No puede agregar el bit setuid en un archivo que no le pertenece, y las implementaciones que permiten regalar archivos borran el bit setuid.

— Gilles 'SO- deja de ser malvado'

Creo que el punto de la respuesta de Dom es este: imagina si pudieras. Entonces habría problemas. Su punto, que no puede, es correcto. Pero el OP pregunta "¿por qué?" Borrar el bit setuid es otra característica de seguridad que nuevamente plantea la pregunta "¿por qué?" Lo que luego me referiría a la respuesta de Dom: SI un usuario pudiera participar, y SI un usuario pudiera configurar, entonces ese combo sería desastroso. Creo que hace un buen punto, incluso si falta un poco.

— Mike S