¿Acceso a archivos en un directorio sin permiso x?


19

Tengo problemas para entender qué significa el permiso de ejecución para los directorios. ¿Entiendo correctamente que algo en un directorio para el que un usuario no tiene derechos x es inaccesible incluso si las cosas dentro del directorio otorgan derechos específicos al usuario?

¿O el usuario todavía tendrá acceso directo a las cosas en el directorio, pero simplemente no puede enumerar lo que está en el directorio?

(Lo que realmente estoy tratando de entender es qué tan seguro es un directorio del acceso de otros usuarios si no tienen permiso x para ello).

Respuestas:


20

x bit para directorio también se llama como bit de búsqueda. En realidad, le permite acceder a los inodos de los archivos enumerados dentro de la carpeta. Entonces, si desea acceder a /home/user/foo/bar.txt, debe tener acceso de búsqueda en cada antepasado de bar.txt

Citando desde la página

Debido a que los directorios no se usan de la misma manera que los archivos normales, los permisos funcionan de manera diferente (pero solo ligeramente). Un intento de listar los archivos en un directorio requiere permiso de lectura para el directorio, pero no en los archivos dentro. Un intento de agregar un archivo a un directorio, eliminar un archivo de un directorio, o cambiar el nombre de un archivo, todos requieren permiso de escritura para el directorio, pero (quizás sorprendentemente) no para los archivos dentro. El permiso de ejecución no se aplica a los directorios (un directorio no puede ser también un programa). Pero ese bit de permiso se reutiliza para directorios para otros fines.

Se necesita permiso de ejecución en un directorio para poder crear un CD en él (es decir, hacer que algún directorio sea su directorio de trabajo actual).

Se necesita ejecutar en un directorio para acceder a la información de inodo de los archivos que contiene. Necesita esto para buscar en un directorio para leer los inodos de los archivos dentro. Por esta razón, el permiso de ejecución en un directorio a menudo se denomina permiso de búsqueda.

Se requiere permiso de búsqueda en muchas situaciones comunes. Considere el comando cat / home / user / foo. Este comando claramente requiere permiso de lectura para el archivo foo. Pero a menos que tenga permiso de búsqueda en los directorios /, / home y / home / user, cat no puede localizar el inodo de foo y, por lo tanto, no puede leerlo. Necesita permiso de búsqueda en cada directorio ancestral para acceder al inodo de cualquier archivo (o directorio), y no puede leer un archivo a menos que pueda acceder a su inodo.

Por favor lea más en sección del directorio de permisos de archivos.

Actualización: Leo hizo una muy buena pregunta. Si conocemos el inodo, ¿podemos acceder a un archivo desde un directorio que tiene un bit x sin establecer? Creo que no deberíamos poder hacerlo. No lo probé con el programa c, sino que utilicé algunos comandos bash útiles para confirmarlo.

user@user-desktop:~/test$ ls -lart
total 12
drwxr-xr-x 49 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x  3 user user 4096 2011-11-30 22:37 .
drwxr-xr-x  2 user user 4096 2011-11-30 22:38 level1
user@user-desktop:~/test$ ls -lart level1/
total 12
drwxr-xr-x 3 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x 2 user user 4096 2011-11-30 22:38 .
-rw-r--r-- 1 user user    8 2011-11-30 22:38 file1
user@user-desktop:~/test$ stat level1
  File: `level1'
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 808h/2056d  Inode: 95494       Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:46:16.576702105 +0530
Modify: 2011-11-30 22:38:12.386701913 +0530
Change: 2011-11-30 22:46:08.876702102 +0530
user@user-desktop:~/test$ stat level1/file1 
  File: `level1/file1'
  Size: 8           Blocks: 8          IO Block: 4096   regular file
Device: 808h/2056d  Inode: 60775       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:38:19.846701917 +0530
Modify: 2011-11-30 22:38:16.366701915 +0530
Change: 2011-11-30 22:38:16.366701915 +0530
user@user-desktop:~/test$ chmod -x level1
user@user-desktop:~/test$ stat level1/file1 
stat: cannot stat `level1/file1': Permission denied
user@user-desktop:~/test$ ls -lart level1/
ls: cannot access level1/..: Permission denied
ls: cannot access level1/.: Permission denied
ls: cannot access level1/file1: Permission denied
total 0
-????????? ? ? ? ?                ? file1
d????????? ? ? ? ?                ? ..
d????????? ? ? ? ?                ? .
user@user-desktop:~/test$ cat level1/file1
cat: level1/file1: Permission denied
user@user-desktop:~/test$ find . -inum 95494
./level1
user@user-desktop:~/test$ find . -inum 60775
user@user-desktop:~/test$ find ./level -inum 60775
find: `./level': No such file or directory
user@user-desktop:~/test$ find ./level1 -inum 60775

2
Entonces, si tengo el número de inodo de un archivo / directorio dentro de un directorio sin derechos de búsqueda, ¿podría acceder a él siempre que sus permisos lo permitan? (Supongo que obtener el número de inodo sin poder hacer estadísticas es bastante difícil).
Leo

@Leo, creo, no deberíamos poder hacerlo. He actualizado la respuesta. Si tiene un pequeño código auxiliar, verifíquelo y avísenos.
Amey Jah

1
@AmeyJah, en realidad, apuesto a que puedes. Tenga en cuenta lo que sucede cuando vincula un archivo a otro directorio para el que tiene permiso. El mismo inodo, pero luego puedes leerlo. En otras palabras, el permiso de lectura no depende de que el sistema busque todas las carpetas a las que pueda pertenecer el inodo y vea si tienen el bit x. Gran respuesta sin embargo. Muchas gracias.
user1477

@AmeyJah ls , stat , etc. usa stat (2), etc. Por si no lo sabías ahora. Podría escribir un programa en C, pero su prueba hace todo lo que el programa mostraría, aunque seguro de que podría hacer más, el punto es el mismo: utiliza las llamadas al sistema (sección 2). Las llamadas a la biblioteca (sección 3) son de mayor nivel que las llamadas al sistema, pero eso no cambia nada (por ejemplo, remove (3) usa rmdir (2) para directorios y unlink (2) para archivos).
Pryftan

5

Como está solicitando directorios:

leer significa: leer los contenidos, es decir, enumerarlos con ls.

escribir significa: escribir en el director. es decir, crear archivos o subdirectorios.

ejecutar significa: entrar en ese directorio.

leer y ejecutar permisos podría ser un poco complicado para los directorios.

Por ejemplo, si tiene permisos de lectura pero no ejecuta, puede enumerar el contenido del directorio pero no puede colocarlo en él. Además, no puede enumerar archivos o directorios específicos aunque conozca sus nombres.

Si tiene permiso de ejecución pero no lee, puede acceder a él pero no puede enumerar los archivos directamente. Pero, si conoce los nombres de los archivos o directorios, puede enumerarlos.


2
Si tiene permiso de lectura pero no ejecuta, puede enumerar (ls) el contenido del directorio pero no puede acceder (cat) a los archivos que contiene. Si tiene permiso de ejecución pero no leyó y conoce los nombres de los archivos a los que puede acceder (cat).
dash17291

2

El permiso de ejecución en directorios significa:

La capacidad de cd en este directorio y acceder a los archivos en este directorio.

Si no tiene el xderecho en su directorio, no puede:

  • Entra en el directorio (es decir: cd)
  • No se puede acceder a ningún archivo en este directorio (incluso si conoce el nombre).

Ejemplo:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ cd testdir
bash: cd: testdir: Permission denied

$ cat testdir/a
cat: testdir/a: Permission denied

$ chmod 700 testdir
$ cat testdir/a
Some text.

Lea Linux File Permission Confusion pt 2 para obtener una buena introducción sobre el tema.

Lo único que el xpermiso no parece evitar es acceder a los nombres de los archivos en ese directorio.

Ejemplo:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ ls testdir
ls: cannot access testdir/a: Permission denied
ls: cannot access testdir/b: Permission denied
a  b
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.