Wie kann ich explizit und sicher die Verwendung eines eingebauten Befehls in bash erzwingen?

Es gibt eine ähnliche Frage , die sich mit dem 'Wrapping'-Szenario befasst, bei dem Sie beispielsweise cdeinen Befehl verwenden möchten , der das eingebaute Element aufruft cd.

Angesichts von Shellshock et al. Und der Tatsache, dass Bash Funktionen aus der Umgebung importiert, habe ich einige Tests durchgeführt und kann das Builtin nicht sicher cdaus meinem Skript aufrufen .

Bedenken Sie

cd() { echo "muahaha"; }
export -f cd

Alle Skripte, die in dieser Umgebung mit aufgerufen cdwerden, brechen ab (berücksichtigen Sie die Auswirkungen von etwas Ähnlichem cd dir && rm -rf .).

Es gibt Befehle zum Überprüfen des Typs eines Befehls (bequemer Aufruf type) und Befehle zum Ausführen der eingebauten Version anstelle einer Funktion ( builtinund command). Aber siehe da, diese können auch mit Funktionen überschrieben werden

builtin() { "$@"; }
command() { "$@"; }
type() { echo "$1 is a shell builtin"; }

Ergibt Folgendes:

$ type cd
cd is a shell builtin
$ cd x
muahaha
$ builtin cd x
muahaha
$ command cd x
muahaha

Gibt es eine Möglichkeit, bash sicher zur Verwendung des integrierten Befehls zu zwingen oder zumindest zu erkennen, dass ein Befehl kein integrierter Befehl ist, ohne die gesamte Umgebung zu löschen?

Mir ist klar, dass Sie wahrscheinlich sowieso bescheuert sind, wenn jemand Ihre Umgebung kontrolliert, aber zumindest für Aliase können Sie den Alias ​​nicht aufrufen, indem Sie ein \davor einfügen .

Olivier D ist fast richtig, aber Sie müssen POSIXLY_CORRECT=1vor dem Laufen einstellen unset. POSIX kennt sich mit speziellen integrierten Funktionen aus , und bash unterstützt dies . unsetist eine solche eingebaut. Suchen nachSPECIAL_BUILTIN in builtins/*.cin der Bash - Quelle für eine Liste, enthält es set, unset, export, evalund source.

$ unset() { echo muahaha-unset; }
$ unset unset
muahaha-unset
$ POSIXLY_CORRECT=1
$ unset unset

Der Schurke unsetist nun aus der Umgebung entfernt, wenn Sie unset command, type, builtindann sollten Sie in der Lage sein, zu gehen , aber unset POSIXLY_CORRECTwenn Sie auf nicht-POSIX - Verhalten oder erweitern bash Funktionen angewiesen sind.

Hiermit werden jedoch keine Aliase behandelt. Sie müssen \unsetalso sicherstellen, dass es in der interaktiven Shell funktioniert (oder immer, falls dies tatsächlich der Fall expand_aliasesist).

Für die paranoid, dies sollte alles reparieren, denke ich:

POSIXLY_CORRECT=1
\unset -f help read unset
\unset POSIXLY_CORRECT
re='^([a-z:.\[]+):' # =~ is troublesome to escape
while \read cmd; do 
    [[ "$cmd" =~ $re ]] && \unset -f ${BASH_REMATCH[1]}; 
done < <( \help -s "*" )

( while, do,done Und [[sind reservierte Worte und keine Vorsichtsmaßnahmen müssen.) Hinweis verwenden wir unset -fauf ungesetzt Funktionen sicher sein, obwohl Variablen und Funktionen denselben Namespace ist es möglich , beide gleichzeitig zu existieren (dank Etan Reisner) , in dem Fall zweimaliges Einstellen würde ebenfalls ausreichen. Sie können eine Funktion schreibgeschützt markieren. Bash hindert Sie nicht daran, eine schreibgeschützte Funktion bis einschließlich Bash-4.2 zu deaktivieren. Bash-4.3 hindert Sie daran, berücksichtigt jedoch weiterhin die speziellen eingebauten Funktionen, wenn diese POSIXLY_CORRECTgesetzt sind.

Ein Readonly POSIXLY_CORRECT ist kein echtes Problem, dies ist kein Boolescher Wert oder ein Flag, dessen Vorhandensein den POSIX-Modus aktiviert. Wenn es also als Readonly existiert, können Sie sich auf POSIX-Funktionen verlassen, auch wenn der Wert leer oder 0 ist. Das müssen Sie einfach ungeklärte problematische Funktionen anders als oben, vielleicht mit etwas Ausschneiden und Einfügen:

\help -s "*" | while IFS=": " read cmd junk; do echo \\unset -f $cmd; done

(und ignorieren Sie alle Fehler) oder engagieren Sie sich in einem anderen Scriptobatics .

Weitere Hinweise:

• functionIst ein reserviertes Wort, kann es mit einem Alias ​​versehen, aber nicht mit einer Funktion überschrieben werden. (Aliasing functionist leicht störend, weil\function es als Umgehungsmöglichkeit nicht akzeptabel ist.)
• [[, ]]sind reservierte Wörter, sie können mit Alias ​​versehen werden (was ignoriert wird), aber nicht mit einer Funktion überschrieben werden (obwohl Funktionen so benannt werden können)
• (( ist weder ein gültiger Name für eine Funktion noch ein Alias

Mir ist klar, dass Sie wahrscheinlich sowieso durcheinander sind, wenn jemand Ihre Umgebung kontrolliert

Ja das. Wenn Sie ein Skript in einer unbekannten Umgebung LD_PRELOADausführen , können alle möglichen Probleme auftreten, angefangen damit, dass der Shell-Prozess beliebigen Code ausführt, bevor er Ihr Skript überhaupt liest. Der Versuch, innerhalb des Skripts vor einer feindlichen Umgebung zu schützen, ist erfolglos.

Sudo hat die Umgebung desinfiziert, indem es seit über einem Jahrzehnt alles entfernt, was wie eine Bash-Funktionsdefinition aussieht. Seit Shellshock sind andere Umgebungen, in denen Shell-Skripts in einer nicht vollständig vertrauenswürdigen Umgebung ausgeführt werden, dem Beispiel gefolgt.

Sie können ein Skript nicht sicher in einer Umgebung ausführen, die von einer nicht vertrauenswürdigen Entität festgelegt wurde. Sich über Funktionsdefinitionen Gedanken zu machen, ist also nicht produktiv. Bereinigen Sie Ihre Umgebung und verwenden Sie dabei Variablen, die von bash als Funktionsdefinitionen interpretiert werden.

Sie können verwenden unset -f, um die Funktionen builtin, command und type zu entfernen.