¿Cuál es el propósito de los permisos de Linux como 111 o 333 (es decir, el usuario puede ejecutar , pero no puede leer el archivo), si la capacidad de ejecución no implica automáticamente la capacidad de leer?
¿Cuál es el propósito de los permisos de Linux como 111 o 333 (es decir, el usuario puede ejecutar , pero no puede leer el archivo), si la capacidad de ejecución no implica automáticamente la capacidad de leer?
Respuestas:
He jugado con él y, al parecer, los permisos Exec no implican permisos de lectura. Binarios pueden ser ejecutables sin ser legibles:
$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw
hello world
$ cat hw
/bin/cat: hw: Permission denied
No puedo ejecutar secuencias de comandos sin embargo, a menos que tengan tanto de lectura y bits de permiso Exec en:
$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied
/bin/bash hw.sh
y luego bash intenta abrirse hw.sh
para leer (y falla).
tiene sentido para los directorios, por ejemplo, si mantiene los archivos ejecutables (secretos) en un directorio específico y luego permite que los usuarios llamen a esos archivos sin poder ver el contenido del directorio (¡pero sabiendo que hay un archivo específico después de informarles!). 333 en comparación con 111 permite escribir / borrar archivos a / desde esos directorios sin ser capaz de ver el contenido del directorio.
Obviamente, no todas las combinaciones son tan útiles, pero para tomar el que menciona específicamente ... En realidad no necesita read
permiso para ejecutar un archivo - solamente execute
el permiso - a menos que el archivo en cuestión es un script (por ejemplo, un script de shell ( .sh
), perl-escritura ( .pl
) y así sucesivamente). Los archivos binarios normales se pueden ejecutar solo con el execute
permiso. En * BSD-systmes, varios ejecutables dan execute
permiso sin permiso read
, especialmente en comandos "importantes para la seguridad", por ejemplo su
.
Entonces, ¿por qué no dar a los usuarios read
permiso (y solo execute
permiso)? ¡Porque un archivo que no puede ser leído por un usuario, tampoco puede ser copiado por ese usuario! Al eliminar el read
permiso, se evita que los usuarios hagan sus propias copias "personales" de ejecutables, que luego pueden abusar (por ejemplo, obtener SUID=root on
).
Y al no tener write
permiso, evita que un archivo se elimine correctamente.
Eso sí, no dar ni read
-ni write
-permission que el propietario es un poco raro, pero a veces puede ser una buena idea para evitar incluso el owner
de simplemente borrar un archivo. Por supuesto, el owner
- por no hablar root
- siempre puede eludir este tipo de medidas, si no en otras formas, a continuación, simplemente por chmod
el permiso en el archivo.
owner
solo eliminen un archivo". - excepto que no necesita ningún tipo de permiso en un archivo (leer, escribir o ejecutar) para eliminarlo.
/proc/${PID}/maps
y luego leer las secciones relevantes de la memoria /proc/${PID}/mem
? ¿O restringir los permisos en el archivo ejecutable también restringe los permisos de lectura en sus secciones relevantes en la memoria durante la ejecución? (Esto último parece poco probable, OMI.)