Tengo una carpeta de proyecto que tiene permisos desordenados en todos los archivos. He tenido la mala tendencia de configurar todo en permisos octales 777 porque resolvió todos los problemas no relacionados con la seguridad. Luego, las cargas FTP, los archivos creados por editores de texto, etc. tienen su propio conjunto de permisos, lo que hace que todo sea un desastre. He decidido recomponerme y comenzar a usar los permisos de la forma en que deben usarse.
Pensé que 664 era un buen valor predeterminado para todos mis archivos y carpetas, y simplemente eliminaría los permisos para otros en archivos privados y agregaría +x para archivos ejecutables.
Sin embargo, en el segundo cambié la carpeta de mi proyecto a 664:
$ sudo chmod -R 664 . $ls ls: no se puede abrir el directorio.: Permiso denegado
Lo cual no tiene sentido para mí. Tengo permisos de lectura/escritura y soy el propietario de la carpeta del proyecto. La parte más a la izquierda de ls -lmi carpeta de proyecto se ve así:
-rw-rw-r-- 1 código mono código mono ... drw-rw-r-- 5 codemonkey codemonkey... -rw-rw-r-- 1 código mono código mono ... -rw-rw-r-- 1 código mono código mono ... drw-rw-r-- 3 codemonkey codemonkey ... -rw-rw-r-- 1 código mono código mono ... -rw-rw-r-- 1 código mono código mono ... -rw-rw-r-- 1 código mono código mono ... drw-rw-r-- 4 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey...
Supongo que esto tiene algo que ver con los permisos de los directorios, pero¿qué?
Respuesta1
El bit de ejecución es necesario para atravesar un directorio *nix. No puede cdacceder a un directorio para el que no tiene permisos de ejecución, y esto afecta a varias utilidades de formas no obvias si necesitan un contexto de directorio. Considerar:
$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo
# You can read the contents of the directory, but ls still complains.
$ ls foo
ls: cannot access foo/bar: Permission denied
bar
# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied
La razón de todo esto es la forma en que funciona stat(). Extraído de man 2 stat:
No se requieren permisos en el archivo en sí, pero, en el caso de stat() y lstat(), se requiere permiso de ejecución (búsqueda) en todos los directorios en la ruta que conduce al archivo.
La conclusión es que un recurso recursivo chmodrara vez hará lo que usted espera y causará estragos en los permisos de lectura y ejecución del directorio que pueden conducir a resultados inesperados como el suyo. Trate siempre los permisos de directorio por separado de los permisos de archivos para obtener mejores resultados.
Respuesta2
Necesita permisos de ejecución en directorios.
Considerar
sudo find -type d -exec chmod +x {} +
Actualización: aquí está mi racionalización de este uso, aparentemente extraño, de permisos de ejecución.
Unix (y por lo tanto Linux) trata prácticamente todo como archivos. Esto se extiende a los discos y a varios otros dispositivos. también incluye directorios.
Los sistemas de archivos Unix tradicionales tienen un conjunto de permisos que se aplican a los archivos. Por lo tanto, los diseñadores de Unix tuvieron que encontrar algo útil para cada bit de permiso cuando se aplicaba a un "archivo" que no era su archivo de datos normal.
Consideremos los directorios. Inicialmente parece razonable usar simplemente el permiso de lectura para decidir si alguien puede acceder al directorio, por ejemplo, para generar una lista de los archivos que contiene y sus tamaños, marcas de fecha, etc.
Sin embargo, supongamos que quiere que los usuarios normales puedan ejecutar programas en /usr/local/bin pero no quiere que puedan hurgar en /usr/local para ver qué hay allí. Si solo tiene permiso de lectura, no podrá evitarlo.
Entonces, el permiso de ejecución, que de otro modo sería redundante, se usó para controlar si su shell puede "atravesar" un directorio, con lo que queremos decir, no descubrir más de lo que se necesita para poder encontrar y leer los detalles de un subdirectorio como parte de un camino. Esto le permite acceder al directorio /usr/local sólo en la medida necesaria para leer el contenido de /usr/local/bin.
Entonces +x en /usr/local significa que puedes ejecutar "/usr/local/bin/foo" Pero +r en /usr/local significa que puedes averiguar todo lo que hay en /usr/local, incluido quién es el propietario y qué permisos tiene cada archivo, que tamaño era, etc.
Lo anterior se basa en vagos recuerdos y conjeturas. Puede que no sea exactamente cierto, pero creo que da una idea razonable de por qué "ejecutar" significa "capaz de atravesar".