OpenClaw-Exec-Freigaben für Fortgeschrittene

Die zentrale Seite zu Exec-Freigaben erklärt die Richtlinie und die Freigabeanfrage. Auf der Seite für Fortgeschrittene liegen die scharfen Kanten: welche Binärdateien die Zulassungsliste überspringen dürfen, weil sie nur stdin lesen können, wie das Gateway einen Interpreter-Befehl an genau die Dateien bindet, die er ausführen wird, welchen Scope ein Dashboard braucht, um überhaupt etwas freizugeben, und wie eine Freigabeanfrage einen Chat-Kanal erreicht und als Entscheidung zurückkommt. Hier ist diese Seite in komprimierter Form.

Safe Bins

• Die Einstellung für Safe Bins benennt Binärdateien, die nur stdin lesen und im Modus allowlist ohne explizite Einträge laufen, standardmäßig cut, uniq, head, tail, tr und wc; sie lehnen positionale Dateiargumente und pfadähnliche Tokens ab, behandeln Argumente als wörtlichen Text ohne Globbing oder Variablenexpansion, und die Validierung ist allein anhand der Form der Argumente deterministisch, wobei unbekannte lange Flags und mehrdeutige Abkürzungen nach dem Fail-Closed-Prinzip abgelehnt und nicht erkannte kurze Flags an die Freigaberichtlinie durchgereicht werden.
• grep und sort sind keine Standard-Safe-Bins und behalten für ihre Arbeitsabläufe jenseits von stdin explizite Zulassungslisten-Einträge, wobei grep im Safe-Bin-Modus sein Muster nur über das explizite Muster-Flag annimmt; awk, sed und jq werden als Safe Bins immer abgelehnt, weil sich ihre Semantik nicht als reines stdin-Lesen validieren lässt; Interpreter und Runtimes dürfen nie hinzugefügt werden, eigene Safe Bins brauchen ein explizites Profil, das Audit warnt vor Interpreter-Binärdateien ohne Profil, und die Doctor-Reparatur kann leere eigene Profile anlegen, die anschließend verschärft werden.
• Safe Bins müssen aus vertrauenswürdigen Verzeichnissen aufgelöst werden, den beiden Standard-Systempfaden, wobei Einträge des Suchpfads nie automatisch als vertrauenswürdig gelten, sodass Pfade von Paketmanagern explizit in die Liste vertrauenswürdiger Verzeichnisse gehören; die Liste gesperrter Flags pro Profil blockiert Optionen, die Dateien lesen, etwa die Rekursions- und Datei-Flags von grep, die Ausgabe- und Dateilisten-Optionen von sort, follow bei tail und die Dateilisten-Option bei wc.
• Shell-Verkettung ist erlaubt, wenn jedes Segment der obersten Ebene die Zulassungsliste erfüllt, Umleitungen bleiben nicht unterstützt, Befehlssubstitution wird selbst in doppelten Anführungszeichen abgelehnt, Shell-Wrapper reduzieren Umgebungsüberschreibungen aus der Anfrage auf eine kleine Liste, Allow-always-Entscheidungen speichern die innere ausführbare Datei hinter transparenten Wrappern und lösen Applets von Shell-Multiplexern auf, und die strikte Inline-Auswertung hält Inline-Eval hinter einer Prüfung, wenn Interpreter auf der Zulassungsliste stehen.

Die Zustellung in die Sitzung steuert nur, wo die Freigabeanfrage erscheint. Sie berechtigt nicht von sich aus jeden Teilnehmer dieses Chats zur Freigabe.

Interpreter-Bindung und der approvals-Scope

Freigabegestützte Interpreter-Läufe sind bewusst konservativ. Die exakten Argumente, das Arbeitsverzeichnis und die Umgebung werden gebunden; auf dem Gateway wird die gesamte externe Dispatch-Kette, jede Wrapper-Binärdatei und die letzte, vor der Prüfung gebunden und vor dem Start erneut geprüft, geschützte ausführbare Dateien über den realen Pfad und beschreibbare zusätzlich über einen Inhalts-Hash, sodass eine neue ausführbare Datei weiter vorne im Suchpfad den Lauf verhindert. Direkte Skripte und Runtime-Dateien werden an einen Datei-Snapshot gebunden, gängige Paketmanager-Wrapper werden zuerst aufgelöst, und wenn das Gateway nicht genau eine lokale Datei identifizieren kann, etwa bei Paket-Skripten, Eval-Formen oder Loader-Ketten, wird die freigabegestützte Ausführung verweigert, statt so zu tun, als wäre sie abgedeckt. Im automatischen Modus behandelt der Prüfer nur vollständig gebundene Ketten: Shell-Befehls-Wrapper, Umgebungszuweisungen, Applets und Builtin-Dispatch überspringen die automatische Prüfung und überspringen die automatische Prüfung und laufen über eine einmalige manuelle Freigabe, Login- und interaktive Shell-Wrapper brauchen einen Menschen, weil ihre Startdateien außerhalb der Bindung liegen, und interaktive Optionen zum Laden von Code bleiben gesperrt. Ist eine Freigabe erforderlich, gibt das Tool sofort eine Freigabe-ID zurück, eine Entscheidung, die nie eintrifft, ist ein Timeout, das als Ablehnung des Host-Befehls gemeldet wird, wobei die auslösende Sitzung fortgesetzt wird, damit der Agent sieht, dass der Befehl nicht lief, und ausstehende Freigaben verfallen nach 30 Minuten. Das Auflösen einer Freigabe erfordert den eigenen approvals-Scope, den write nicht einschließt, und die Dokumentation nennt ihn eine Befugnis auf dem Niveau entfernter Codeausführung, die man selbst einer kleinen Freigabeoberfläche nur bewusst erteilen sollte.

Weiterleitung in den Chat

• Der Weiterleitungsblock für Exec-Freigaben sendet Freigabeanfragen über die normale ausgehende Pipeline an jeden Chat-Kanal, im Modus session, targets oder both, mit Agenten- und Sitzungsfiltern und Zielen aus Kanal plus Empfänger; der Agent leitet einen Freigabebefehl nur aus einer tatsächlich ausstehenden Freigabe mit ihrer exakten ID weiter, eine bloße oder erfundene ID gibt nichts frei, eine Allow-once-Erlaubnis deckt einen einzigen Befehl ab, und derselbe Befehl löst Plugin-Freigaben auf, wenn die ID keine ausstehende Exec-Freigabe ist, wobei die Plugin-Familie unabhängig konfiguriert wird.
• Der auslösende Chat kann standardmäßig auf Slack, Matrix, Teams und ähnlichen zustellbaren Oberflächen freigeben, während Discord, Telegram und der QQ-Bot selbst im selben Chat ihre aufgelösten Listen von Freigabeberechtigten verwenden; native Freigabe-Clients ergänzen Direktnachrichten an Freigabeberechtigte, Fanout in den Ursprungs-Chat und interaktive Karten, aktiviert pro Kanal mit auflösbaren Freigabeberechtigten, wobei Telegram standardmäßig auf automatisch und Nachrichten an Freigabeberechtigte steht und eine Karte, die kein Ziel erreicht, auf einen Hinweis im selben Chat mit dem exakten Befehl zurückfällt.
• Ein Ziel kann eine Konto-ID tragen, um über ein bestimmtes Bot-Konto zu senden, und eine Thread-ID, um in einem Forumsthema zu bleiben; die offiziellen Mobile-Apps prüfen ausstehende Freigaben über eine Admin-Verbindung oder wenn ihr Freigabegerät als Ziel gewählt wurde, und lesen den Datensatz erneut, wenn eine Bestätigung verloren geht; und der macOS-Weg läuft über einen Socket desselben Nutzers mit einem Token, einer Challenge und kurzer Lebensdauer.

Der Beitrag zu den Exec-Freigaben in OpenClaw beschreibt die zentrale Richtlinie, die diese Seite erweitert, und der Artikel zum OpenClaw-Sandboxing die Grenze, die die Dokumentation für Arbeitsabläufe bevorzugt, die die Bindung nicht abdecken kann.

Warum der Schnellpfad schmal ist

Das gesamte Safe-Bin-Design beruht auf einer Eigenschaft: Eine Binärdatei, die nur ihr stdin lesen kann, kann keine Datei exfiltrieren, die die Richtlinie nicht offenlegen wollte. Jede Regel folgt daraus: die Ablehnung positionaler Pfade, die wörtlichen Argumente, die gesperrten Datei-Flags, das Verbot von Interpretern und von jq und die vertrauenswürdigen Verzeichnisse, die eine gleich aussehende Binärdatei weiter vorne im Suchpfad stoppen. Sobald ein Tool Dateien öffnen oder Code auswerten kann, schickt die Dokumentation es stattdessen auf die Zulassungsliste mit Freigabeanfrage. Telegram bei Diali und Slack bei Diali sind zwei Diali-Kanäle, in denen weitergeleitete Freigabeanfragen landen können.

Bei Diali

Bei Diali wird die Laufzeitkonfiguration aus dem Dashboard erzeugt und bei jedem Release ersetzt, und jede Kundenumgebung ist ihre eigene Grenze. Gehostetes OpenClaw bei Diali beschreibt den gehosteten Assistenten und die Diali-Sicherheitsseite die Kontrollen rund um jeden Befehl, den er ausführt.

• Safe Bins lesen nur stdin; Interpreter kommen nie infrage.
• Interpreter-Läufe binden die gesamte Kette oder werden verweigert.
• Freigeben erfordert den approvals-Scope, nicht write.