@willy4711: Dieser Fall (`chmod 001') wurde schon oben gezeigt und er entspricht dem was ich behauptet habe. Interessant ist der Fall, wenn *kein* Executable-Bit gesetzt ist und selbst root die Datei dann nicht ausfuehren darf.
Hier eine Shell-Session dazu:
Code: Alles auswählen
:-L cd /tmp
:-L ed a
a: No such file or directory
a
#!/bin/sh
echo foo
.
w
19
q
:-L chmod 000 a
:-L ll a
---------- 1 meillo meillo 19 2019-11-04 13:06 a
:-L sudo ./a
[sudo] password for meillo:
sudo: ./a: command not found
:-L sudo /tmp/a
sudo: /tmp/a: command not found
:-L chmod g+x a
:-L ll a
------x--- 1 meillo meillo 19 2019-11-04 13:06 a*
:-L sudo /tmp/a
foo
:-L cat a
mksh: cat: a: Permission denied
:-L sudo cat a
#!/bin/sh
echo foo
:-L sudo bash a
foo
:-L chmod 000 a
:-L ll a
---------- 1 meillo meillo 19 2019-11-04 13:06 a
:-L sudo bash a
foo
:-L
Ich vermute mal, dass folgendes der Hintergrund ist: Frueher war es ueblich `.' in $PATH zu haben, und zwar vorne dran. Ausfuehrbare Dateien im aktuellen Verzeichnis werden dann aufgerufen, wenn man ihren Namen auf der Kommandozeile eingibt. Wenn root alles ausfuehren koennte, dann wuerde jede Datei im aktuellen Verzeichnis ausgefuehrt werden, wenn man ihren Namen als Befehl eingibt. Die meisten Dateien kann man gar nicht ausfuehren, insofern macht es Sinn, dies auch nicht zu tun, es sei denn, sie waeren als ausfuehrbar gekennzeichnet ... fuer root ist dann aber egal wo.
Das betrifft nur das Ausfuehren von Dateien, nicht aber das Executable-Bit mit seiner Bedeutung fuer Directories:
Code: Alles auswählen
:-L mkdir b
:-L touch b/c
:-L chmod 000 b
:-L ll -d b
d--------- 2 meillo meillo 4096 2019-11-04 13:14 b/
:-L ls b
ls: cannot open directory b: Permission denied
:-L cd b
mksh: cd: /tmp/b: Permission denied
:-L sudo ls b
c
:-L sudo bash -c 'cd b; ls'
c
:-L