¿Por qué la raíz no puede ejecutarse cuando los bits ejecutables no están configurados?

rootel usuario puede escribir en un archivo incluso si sus writepermisos no están establecidos.

rootel usuario puede leer un archivo incluso si sus readpermisos no están establecidos.

rootel usuario puede cd ingresar a un directorio incluso si sus executepermisos no están establecidos.

rootel usuario no puede ejecutar un archivo cuando sus executepermisos no están establecidos.

¿Por qué?

user$ echo '#!'$(which bash) > file
user$ chmod 000 file
user$ ls -l file
---------- 1 user user 12 Jul 17 11:11 file
user$ cat file                      # Normal user cannot read
cat: file: Permission denied
user$ su
root$ echo 'echo hello' >> file     # root can write
root$ cat file                      # root can read
#!/bin/bash
echo hello
root$ ./file                        # root cannot execute
bash: ./file: Permission denied

En resumen, porque el bit de ejecución se considera especial; Si no se establece en absoluto , entonces el archivo se considera que no es un archivo ejecutable y por lo tanto no puede ser ejecutado.

Sin embargo, si incluso UNO de los bits de ejecución está configurado, root puede ejecutarlo y lo ejecutará.

Observar:

caleburn: ~/ >cat hello.sh
#!/bin/sh

echo "Hello!"

caleburn: ~/ >chmod 000 hello.sh
caleburn: ~/ >./hello.sh
-bash: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
sudo: ./hello.sh: command not found

caleburn: ~/ >chmod 100 hello.sh
caleburn: ~/ >./hello.sh
/bin/sh: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
Hello!

En las viejas herramientas de administración del sistema día vivido en /etccomo /etc/restore, /etc/rrestore, /etc/init, /etc/halt, etc. imaginar lo que pasaría si root's PATHse establecen en /etc:/biny rootcorrió passwd.

No funcionaría bien.

Para empeorar las cosas, en los viejos tiempos, los ejecutables binarios no tenían encabezados mágicos, por lo que verificar si el binario era un ejecutable no era realmente posible, excepto verificando los bits de permiso. Entonces hicieron que los archivos no fueran objetivos válidos de exec* a menos que fueran realmente archivos (sin directorios, etc.) y tuvieran al menos un conjunto de bits de ejecución.

* La verificación podría haber estado en execvp, que es una función de modo de usuario.

Todavía es una verificación útil, ya que en teoría cualquier cosa podría ser un script de shell, entonces, ¿por qué eliminarlo?