La carpeta con SOLO permiso de escritura es inútil ... ¿verdad?


10

Después de haber trabajado con Linux durante años, y encontrándome con algo de tiempo libre, decidí revisar algunos conceptos básicos. Así que releí las cosas sobre los permisos (sin verificar el código fuente) y sus casos especiales para carpetas, y se me ocurrió una nueva forma (al menos para mí ...) de pensar sobre los permisos de carpeta (para un usuario específico / grupo / otros): imagino una carpeta como una tabla con dos columnas, así:

filename | inode    
foo      | 111  
bar      | 222 

El permiso de lectura significa que puede leer (y enumerar) la columna izquierda de la tabla, el permiso de escritura corresponde a agregar y eliminar entradas a la tabla, y el permiso de ejecución corresponde a poder traducir del nombre del archivo al inodo; es decir, puede acceder al contenido de la carpeta.

Hice algunos experimentos, y los resultados son todos consistentes con esta "visión del mundo" mía, pero una conclusión parece inevitable: que una carpeta con permisos d-w-------es totalmente inútil. Elaboración: no puede enumerar su contenido, no puede leer ningún archivo que sepa que existe dentro (porque no puede traducir nombres a inodes), no puede eliminar o renombrar o agregar archivos, porque de nuevo eso implicaría traducción , y ni siquiera puede agregar enlaces duros (porque, supongo, eso significaría agregar un nombre y un número de inodo, lo que significa que conocería ambos, lo que a su vez, una vez más, viola el propósito de desarmar el permiso de ejecución) . Y, por supuesto, si no son los archivos dentro de una de estas carpetas, entonces usted no puede eliminar esa carpeta o bien, porque no se puede eliminar sus contenidos.

Entonces ... me gustaría hacer dos preguntas:

  1. ¿Es correcta esta analogía mía o es un gran error?
  2. Independientemente de la respuesta anterior, ¿hay alguna situación en la que sea apropiado tener una carpeta con los permisos descritos?

3
Puede ser que no todas las combinaciones sean útiles. Por ejemplo, en inglés tenemos palabras, estas palabras están formadas por letras, no todas las combinaciones forman palabras válidas. p.ej. aoeuidhtns
ctrl-alt-delor

De esta manera, ¿no podría, por ejemplo, crear un archivo? Usted solicita al espacio del sistema de archivos y nodo-i, y después de escribir el nombre y inodo en la tabla de directorio. Debería tener solo el problema de tener 2 archivos con el mismo nombre pero con un inodo diferente en el mismo directorio ...
Hastur

@Hastur: Yo también lo pensé, pero después de mkdir foo ; chmod 200 foo ; touch foo/barque llegue touch: cannot touch ‘foo/bar’: Permission denied. Esto sucede incluso si ya existe foo / bar. Estoy probando en bash (Arch Linux).
wmnorth

Mi culpa estaba pensando que estabas reescribiendo desde el código fuente del sistema ... no podemos tener dos archivos con el mismo nombre en el mismo directorio, por lo que es lógico que esté prohibido dar la posibilidad de crearlo.
Hastur

Sí, es inútil. La resolución del inodo también requiere "x" y "r", por lo que en los directorios, incluso un solo "rw" es inútil.
peterh - Restablece a Mónica el

Respuestas:


3

Tu comprensión es bastante correcta. Una mejor manera de pensar en el permiso de ejecución es que le permite hacer cosas con un nombre de archivo o directorio en el directorio (aparte de simplemente leer el nombre en sí). La mayoría de esas cosas implican traducir el nombre a un inodo, pero también incluye crear nuevos nombres y eliminar nombres existentes.

El permiso de escritura en el directorio sin ejecutar es, por lo tanto, bastante inútil, ya que no hay nada que pueda escribir si no puede acceder a los archivos que contiene.


1
  1. ¿Es correcta esta analogía mía o es un gran error?

Creo que es correcto, necesitas permiso de wx para poder escribir en una carpeta.

  1. Independientemente de la respuesta anterior, ¿hay alguna situación en la que sea apropiado tener una carpeta con los permisos descritos?

Puede tener un proceso que escribe información en una carpeta y otra la consume, pero debe evitar que el escritor lea otra información almacenada en ese lugar.

La situación descrita anteriormente es útil en las unidades automáticas de control de velocidad. Estas unidades deben pasar por un proceso de verificación donde el oficial del estado debe minimizar las posibilidades de adulteración. Algunas unidades automáticas de control de velocidad tienen una tarjeta de memoria SD externa donde el sistema almacena registros de violación. Pero también podría almacenar un archivo de configuración "mágico" que cambia ilegalmente el comportamiento de la unidad verificada. Por lo tanto, el proceso que escribe el registro de violación no debe poder leer nada de la tarjeta de memoria SD.

Aquí es un ejemplo, primero con solo escritura, y luego cómo hacerlo funcionar con wx:

Montar un dispositivo

root@leon:/media# mount -o umask=527,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/media# ls /media/pen/ -la
total 44
d-w-r-x--- 10 enforcer ftp  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

luego, con el ejecutor del usuario, intente escribir un nuevo archivo

enforcer@leon:~$ touch /media/pen/hola
touch: cannot touch ‘/media/pen/hola’: Permission denied

desmontar y volver a montar con wx

root@leon:/media# umount /dev/sdb1
root@leon:/media# mount -o umask=427,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/home/jjorge# ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer wim  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

Inténtalo de nuevo

enforcer@leon:~$ touch /media/pen/hola
enforcer@leon:~$ ls /media/pen/
ls: cannot open directory /media/pen/: Permission denied
enforcer@leon:~$ cat /media/pen/hola
cat: /media/pen/hola: Permission denied

ftp@leon:/home/jjorge$ ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer ftp  4096 Oct 20 10:20 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..
--wxr-x---  1 enforcer wim     0 Oct 20 10:20 hola

Con esta configuración, ahora puede escribir

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.