Mit Bash sourceist es möglich, ein Skript auszuführen, ohne dass ein Ausführungsbit gesetzt ist. Dies ist ein dokumentiertes und erwartetes Verhalten, aber verstößt dies nicht gegen die Verwendung eines Ausführungsbits?
Ich weiß, dadurch sourcewird keine Unterschale erstellt.
Antwort1
sourceoder gleichwertig, jedoch StandardPunkt.führe das Skript nicht aus, aberlesendie Befehle aus der Skriptdatei und führen Sie sie dann Zeile für Zeile in der aktuellen Shell-Umgebung aus.
Es spricht nichts gegen die Verwendung von Execution Bits, da die Shell nurlesenBerechtigung zum Lesen des Dateiinhalts.
Das Ausführungsbit wird nur benötigt, wenn Sielaufendas Skript. Hier wird die Shell fork()den neuen Prozess dann mitexecve()Funktion zum Erstellen eines neuen Prozessabbilds aus dem Skript, das eine normale, ausführbare Datei sein muss.
Antwort2
Bash ist ein Interpreter; es akzeptiert Eingaben und macht, was es will. Es muss das ausführbare Bit nicht beachten. Tatsächlich ist Bash portabel und kann auf Betriebssystemen und Dateisystemen ausgeführt werden, die kein Konzept eines ausführbaren Bits haben.
Was sich um das ausführbare Bit kümmert, ist der Betriebssystemkernel. Wenn der Linux-Kernel execbeispielsweise eine ausführt, prüft er, ob das Dateisystem nicht mit einer noexecOption gemountet ist, er prüft das ausführbare Bit der Programmdatei und erzwingt alle Anforderungen, die von Sicherheitsmodulen (wie SELinux oder AppArmor) gestellt werden.
Beachten Sie, dass das ausführbare Bit eine eher diskretionäre Art der Steuerung ist. Auf einem Linux x86-64-System können Sie beispielsweise die Überprüfung des ausführbaren Bits durch den Kernel umgehen, indem Sieexpliziter Aufruf /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2als Interpreter:
cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls
Dies ist in gewisser Weise analog zum Sourcing von Bash-Quellcode in Bash, mit dem Unterschied, dass es ld.sosich hierbei um den Interpreter handelt und der von ihm ausgeführte Code Maschinencode im ELF-Format ist.
Antwort3
Das ausführbare Bit (im Gegensatz zum Rest) bei nicht-setuid- und nicht-setguid-Dateien ist kein wirklicher Sicherheitsmechanismus. Alles, was Sie lesen können, können Sie indirekt ausführen, und Linux lässt Sie indirekt alles lesen, was Sie ausführen, aber nicht direkt lesen können (das sollte ausreichen, um das Konzept des nicht-set(g)uid-x-Bits als Sicherheitsmaßnahme zu durchbrechen).
Es ist eher eine Frage der Bequemlichkeit: Das System soll es direkt für mich ausführen, wenn das Bit gesetzt ist, andernfalls muss ich es indirekt tun ( bash the_script;oder einigeHacken, um das Speicherabbild einer ausführbaren Datei ohne Leseberechtigung zu erhalten).
Sie können es der Einfachheit halber festlegen, wenn Sie Ihr Unzulässiges sowohl intern beschaffen als auch ausführen möchten.
Offensichtlich teilen jedoch viele Implementierer von gemeinsam genutzten Bibliotheken Ihre Ansicht und daher erfordern viele Systeme, dass gemeinsam genutzte Bibliotheken, die im Wesentlichen das native Äquivalent von Shell-Insourcables sind, als ausführbar gekennzeichnet werden, um verwendet werden zu können. SieheWarum sind gemeinsam genutzte Bibliotheken ausführbar?.
Antwort4
Für das Betriebssystem sind Dateien, die Shell-Skripte enthalten, nur Daten. Wenn Sie den Namen einer solchen Datendatei an den sourceBefehl übergeben oder ihn in der Befehlszeile an einen Aufruf der Bash-Shell übergeben, sieht das Betriebssystem nur eine Zeichenfolge, die zufällig mit dem Namen einer Datei übereinstimmt, die Daten enthält.
Welche Relevanz hätte das Ausführungsbit in diesem Fall?