Es gibt hier ein großes Missverständnis. Machen wir diese Dinge klar.
Zuallererst ist die Einschränkung, auf die Sie sich beziehen, nicht richtig :
Wenn jedoch ein Skript (eine Textdatei, die mit einer She-Bang-Zeile beginnt; dh eine Zeile, die mit beginnt
#!) an einige Shells (Bash) übergeben wird, wird die in dieser Zeile genannte ausführbare Datei (zB/usr/bin/perl) ausgeführt und die Verbindung hergestellt Inhalt der Skriptdatei auf die Standarddatei dieser ausführbaren Datei, die sich möglicherweise nicht auf diesem Laufwerk befindet.
Überraschenderweise scheint es , trotznoexec, die Fähigkeit zur Ausführung zu erklären . Ich glaube, der Fragesteller hat das alles falsch verstanden und es war nicht seine oder ihre Schuld! Eine falsche Annahme in der Frage verursachte eine andere falsche Annahme in der Antwort.
Was ist dann los?
1. Bind Mount ist spezifisch
Um etwas Kontext zu erhalten, schauen wir uns an, was passiert, wenn Sie versuchen, Mount schreibgeschützt zu binden. Es gibt folgende Frage: Warum mounten Sie nicht die schreibgeschützte Option für Bind-Mounts? Die Schlussfolgerung lautet:
Um das gewünschte Ergebnis zu erzielen, müssen Sie zwei Befehle ausführen:
mount SRC DST -o bind mount DST -o remount,ro,bindNeuere Versionen von mount (util-linux> = 2.27) führen dies automatisch aus, wenn eine ausgeführt wird
mount SRC DST -o bind,ro
Aber wenn Sie versuchen, noexecstatt zu verwenden ro, benötigen Sie noch zwei Befehle! In meinem Kubuntu habe ich util-linux 2.27.1-6ubuntu3.3und diesen Befehl:
mount SRC DST -o bind,noexec ignoriert noexec, muss ich neu aufstellen. Es ist dasselbe, wenn die Montage über erfolgt /etc/fstab. Sie können experimentieren. Prüfen Sie jederzeit mit einfachem mountBefehl, welche Optionen es gibt.
Ich wette, der Fragende dachte, das Reittier wäre mit noexecOption, aber eigentlich nicht. Er oder sie war in der Lage, ein Skript innerhalb des angeblich noexecMountpoint auszuführen . Es war seltsam, daher die Frage.
Dann hat der Antwortautor dies interpretiert, als ob es die Shell war, die shebang liest, eine andere ausführbare Datei aufruft und sich keine Sorgen um noexecdas Skript macht. Wenn der Mountpoint wirklich war, noexecwäre das eine vernünftige Spekulation.
Aber…
2. Es ist ein verbreiteter Mythos, dass Muscheln Shebangs lesen; Kernel tut
Lesen Sie wie das #! Shebang Arbeit? und eine der Antworten dort war ursprünglich dem Mythos gefolgt, dann wurde es korrigiert.
Wenn Sie also
- ein Mountpoint
/mnt/foo/mitnoexecOption, - ein Skript,
/mnt/foo/script.pydas ansonsten ausführbar ist (zBchmod -x …aufgerufen wurde), - Ein Shebang gefällt
#!/usr/bin/pythonals erste Zeile im Skript
und du lässt es so laufen
/mnt/foo/script.py Dann lässt Sie Ihr Linux-Kernel nicht wegen noexec. In dieser anderen Frage wäre es passiert, wenn die Montierung tatsächlich noexecda wäre; aber ich glaube es war nicht.
3. Es gibt jedoch zwei Möglichkeiten, ein Skript "auszuführen"
Aus den Kommentaren:
"und werde versuchen, es auszuführen" Wie? Durch direktes Ausführen oder durch Übergabe an den Dolmetscher?
Direkt laufen heißt:
/mnt/foo/script.py Dies wird, noexecwie oben ausgeführt, ehren . Die ausführbare Datei ist script.py .
Die Übergabe an den Dolmetscher bedeutet:
python /mnt/foo/script.py In diesem Fall ist die ausführbare Datei python. Es ist egal, ob foo/mit montiert wird noexec; es spielt keine Rolle, ob überhaupt script.pyausführbar ist; Es ist egal, was der Shebang ist. Der Punkt wird script.pynicht ausgeführt, sondern gelesen .
Solange der Benutzer eine Datei lesen und einen geeigneten Interpreter ausführen kann, kann die Weitergabe der Datei an den Interpreter nicht verhindert werden. aber es ist nicht die Datei, die ausgeführt wird.