Pourquoi le root ne peut-il pas s'exécuter lorsque les bits exécutables ne sont pas définis?

26

rootl'utilisateur peut écrire dans un fichier même si ses writeautorisations ne sont pas définies.

rootl'utilisateur peut lire un fichier même si ses readautorisations ne sont pas définies.

rootl'utilisateur peut cd dans un répertoire même si ses executeautorisations ne sont pas définies.

rootl'utilisateur ne peut pas exécuter un fichier lorsque ses executeautorisations ne sont pas définies.

Pourquoi?

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
musa
la source

Réponses:

25

En bref, parce que le bit d'exécution est considéré comme spécial; s'il n'est pas défini du tout , le fichier n'est pas considéré comme un exécutable et ne peut donc pas être exécuté.

Cependant, si même UN des bits d'exécution est défini, root peut et l'exécutera.

Observer:

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!
Shadur
la source
0

Dans les temps anciens outils d'administration du système vécu dans /etctels que /etc/restore, /etc/rrestore, /etc/init, /etc/halt, etc. Imaginez ce qui arriverait si root« s PATHa été fixé à /etc:/binet rootRAN passwd.

Ça ne marcherait pas bien.

Pour aggraver les choses, dans le passé, les exécutables binaires n'avaient pas d'en-têtes magiques, donc vérifier si le binaire était un exécutable n'était pas vraiment possible, sauf en vérifiant les bits d'autorisation. Ils ont donc fait des fichiers des cibles non valides de exec* sauf s'ils étaient en fait des fichiers (pas de répertoires, etc.) et avaient au moins un bit d'exécution défini.

* La vérification peut avoir été effectuée dans execvp, qui est une fonction en mode utilisateur.

C'est toujours une vérification utile car en théorie, tout pourrait être un script shell, alors pourquoi le retirer?

Joshua
la source