¿Por qué rm puede eliminar un archivo propiedad de un usuario diferente?

De la publicación ¿Por qué rm puede eliminar archivos de solo lectura? Entiendo que rmsolo necesita permiso de escritura en el directorio para eliminar el archivo. Pero me resulta difícil digerir el comportamiento en el que podemos eliminar fácilmente un archivo cuyo propietario y grupo son diferentes.

Probé lo siguiente

mtk: mi nombre de usuario
abc: creó un nuevo usuario

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

Estaba pensando que esto no debería haberse permitido. ¿Un usuario debería poder eliminar solo los archivos de su propiedad? ¿Alguien puede arrojar luz sobre por qué esto está permitido? ¿Y cuál es la forma de evitar esto? Solo puedo pensar en restringir el permiso de escritura del directorio principal para deshabilitar las eliminaciones de archivos por sorpresa.

— mtk
fuente

Respuestas:

100

La razón por la cual esto está permitido está relacionado con lo que realmente hace la eliminación de un archivo. Conceptualmente, rmel trabajo es eliminar una entrada de nombre de un directorio. El hecho de que el archivo se vuelva inalcanzable si ese fuera el único nombre del archivo y que el inodo y el espacio ocupado por el archivo puedan recuperarse en ese punto es casi incidental. El nombre de la llamada al sistema que rminvoca el comando, que es unlink, incluso sugiere este hecho.

Y, eliminar una entrada de nombre de un directorio es fundamentalmente una operación en ese directorio , por lo que ese directorio es lo que necesita tener permiso para escribir.

¿El siguiente escenario puede hacerlo sentir más cómodo? Supongamos que hay directorios:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

Y hay un archivo que me pertenece y que tiene dos enlaces duros:

/home/me/myfile
/home/you/myfile

No importa cómo ese enlace duro /home/you/myfilellegó allí en primer lugar. Tal vez rootponerlo allí.

La idea de este ejemplo es que se le debería permitir eliminar el enlace duro /home/you/myfile. Después de todo, está abarrotando su directorio. Usted debe ser capaz de controlar lo que hace y no existe en el interior /home/you. Y cuando elimine /home/you/myfile, observe que en realidad no ha eliminado el archivo. Solo ha eliminado un enlace a él.

Tenga en cuenta que si el sticky bit se encuentra en el directorio que contiene un archivo (se muestra como ten ls), entonces se hace necesario ser el propietario del archivo con el fin de poder suprimir (a menos que el propietario del directorio). La parte adhesiva generalmente está activada /tmp.

— Celada
fuente

Con el bit adhesivo en el directorio, debe poder modificar el archivo para poder eliminarlo. Es decir, si el archivo pertenece a otra persona del mismo grupo que usted y el grupo puede escribir en el archivo, puede eliminar el archivo. Corolario: cualquiera puede eliminar un archivo con permiso de escritura pública. (Todo sujeto a poder modificar el directorio, por supuesto.)

— Jonathan Leffler

Puede que te esté malinterpretando, pero ¿no estás diciendo que puedo eliminarlo -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/foocomo mi usuario habitual ( /tmpes pegajoso) porque puedo escribirlo? Sin embargo no puedo.

— Celada

Creo que el escenario me/ youtiene un enfoque más claro si se plantea la hipótesis de que el usuario (el que no posee el archivo) creó el enlace. Los pronombres son difíciles de usar; supongamos que Al crea /home/al/file1, y Bob, que tiene acceso para ejecutar (y tal vez leer) /home/al, vincula el archivo a él /home/bob/als_file. En caso de impedimento Bob de la eliminación de un enlace que se creó? ¿Y debería permitirse a Al eliminar (desvincular) /home/bob/als_filecuando no tiene acceso de escritura /home/bob? Este camino lleva al caos.

— Scott

@JonathanLeffler: Como muestra el ejemplo de Scott, no, desvincular y truncar no tienen el mismo resultado neto cuando hay enlaces duros en juego.

— Kevin

@Kevin Creo que el punto es que si alguien tiene permiso de escritura para el archivo, de modo que pueda destruir el contenido, entonces también se le podría permitir desvincularlo (suponiendo que también tenga permiso de escritura para el directorio). Lo contrario no se aplica: ser capaz de eliminar el archivo de un directorio no significa que deba poder destruir el contenido, ya que puede ser accesible desde otro directorio. Esta es la lógica detrás de cómo funciona el bit adhesivo.

— Barmar

Para eliminar un archivo, solo necesita poder escribir en el directorio en el que se encuentra el archivo.

Si no le gusta esto, puede configurar el bit "adhesivo" a través de chmod +t dirsi está en un SO medio reciente (esta característica se introdujo alrededor de 1986 en SunOS).

Si desea ser más fino, necesita un sistema de archivos con una implementación moderna de ACL como ZFS. Las ACL NFSv4 estándar basadas en NTFS incluyen soporte para permisos de eliminación específicos de archivo por usuario y un permiso "delete_child" para directorios.

— astuto
fuente

Tenga en cuenta que para agregar el tbit, debe ser el propietario del directorio. Y si posee el directorio, siempre puede eliminar archivos independientemente de si el tbit está configurado o no. Si vincula un archivo al directorio de otra persona, debe estar preparado para que otra persona pueda eliminarlo. Una alternativa sería crear primero un subdirector tuyo y agregar el archivo allí, ya que el propietario no podría eliminar ese subdirectorio si no está vacío.

— Stéphane Chazelas

Describe la situación de manera engañosa. Técnicamente, un archivo no está en un directorio; más bien, el nombre de un archivo está en el directorio y rmes una operación en el directorio, no en el archivo. Un archivo se elimina cuando se elimina la última referencia, pero técnicamente, eso es un efecto secundario.

— reinierpost

La lógica es similar a la de una casa: el propietario o inquilino decide qué invitados desechar, sin importar quién sea el propietario. Además, el invitado desalojado que es bienvenido en otra casa (tiene otro enlace en el directorio de otra persona) no se congelará hasta morir afuera.

— rackandboneman
fuente