Zatwierdzenia wykonania — zaawansowane

Zaawansowane tematy zatwierdzania exec: szybka ścieżka safeBins, wiązanie interpretera/środowiska uruchomieniowego oraz przekazywanie zatwierdzeń do kanałów czatu (w tym dostarczanie natywne). Zasadniczą politykę i przepływ zatwierdzania opisuje zatwierdzanie exec.

# Bezpieczne binaria (tylko stdin)

tools.exec.safeBins definiuje krótką listę binariów tylko stdin (na przykład cut), które mogą działać w trybie allowlisty bez jawnych wpisów allowlisty. Bezpieczne binaria odrzucają pozycyjne argumenty plików i tokeny podobne do ścieżek, więc mogą działać tylko na przychodzącym strumieniu. Traktuj to jako wąską szybką ścieżkę dla filtrów strumieniowych, a nie ogólną listę zaufania.

Domyślne bezpieczne binaria:

cut, uniq, head, tail, tr, wc

grep i sort nie znajdują się na domyślnej liście. Jeśli się na nie zdecydujesz, zachowaj jawne wpisy allowlisty dla ich przepływów innych niż stdin. Dla grep w trybie bezpiecznego binarium podaj wzorzec przez -e/--regexp; forma wzorca pozycyjnego jest odrzucana, aby operandów plików nie dało się przemycić jako niejednoznacznych argumentów pozycyjnych.

# Walidacja argv i zabronione flagi

Walidacja jest deterministyczna wyłącznie na podstawie kształtu argv (bez sprawdzania istnienia w systemie plików hosta), co zapobiega zachowaniu wyroczni istnienia plików wynikającemu z różnic między zezwoleniem a odmową. Opcje zorientowane na pliki są zabronione dla domyślnych bezpiecznych binariów; długie opcje są walidowane w trybie fail-closed (nieznane flagi i niejednoznaczne skróty są odrzucane).

Zabronione flagi według profilu bezpiecznego binarium:

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• wc: --files0-from

Bezpieczne binaria wymuszają też traktowanie tokenów argv jako tekstu literalnego podczas wykonywania (bez globowania i bez rozwijania $VARS) dla segmentów tylko stdin, więc wzorce takie jak * lub $HOME/... nie mogą zostać użyte do przemycenia odczytów plików.

# Zaufane katalogi binariów

Bezpieczne binaria muszą być rozwiązywane z zaufanych katalogów binariów (domyślne systemowe plus opcjonalne tools.exec.safeBinTrustedDirs). Wpisy PATH nigdy nie są automatycznie uznawane za zaufane. Domyślne zaufane katalogi są celowo minimalne: /bin, /usr/bin. Jeśli plik wykonywalny bezpiecznego binarium znajduje się w ścieżkach menedżera pakietów/użytkownika (na przykład /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin), dodaj je jawnie do tools.exec.safeBinTrustedDirs.

# Łączenie poleceń powłoki, wrappery i multipleksery

Łączenie poleceń powłoki (&&, ||, ;) jest dozwolone, gdy każdy segment najwyższego poziomu spełnia wymagania allowlisty (w tym bezpieczne binaria lub automatyczne zezwolenie umiejętności). Przekierowania pozostają nieobsługiwane w trybie allowlisty. Podstawianie poleceń ($() / backticks) jest odrzucane podczas parsowania allowlisty, również wewnątrz podwójnych cudzysłowów; użyj pojedynczych cudzysłowów, jeśli potrzebujesz literalnego tekstu $().

W zatwierdzeniach aplikacji towarzyszącej na macOS surowy tekst powłoki zawierający składnię sterowania powłoką lub rozwijania (&&, ||, ;, |, `, $, <, >, (, )) jest traktowany jako brak trafienia allowlisty, chyba że samo binarium powłoki znajduje się na allowliście.

Dla wrapperów powłoki (bash|sh|zsh ... -c/-lc) nadpisania env zakresu żądania są redukowane do małej jawnej allowlisty (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR).

Dla decyzji allow-always w trybie allowlisty znane wrappery dyspozytorskie (env, nice, nohup, stdbuf, timeout) utrwalają ścieżkę wewnętrznego pliku wykonywalnego zamiast ścieżki wrappera. Multipleksery powłoki (busybox, toybox) są rozwijane dla apletów powłoki (sh, ash itd.) w taki sam sposób. Jeśli wrappera lub multipleksera nie da się bezpiecznie rozwinąć, żaden wpis allowlisty nie jest automatycznie utrwalany.

Jeśli dodajesz do allowlisty interpretery takie jak python3 lub node, preferuj tools.exec.strictInlineEval=true, aby inline eval nadal wymagał jawnego zatwierdzenia. W trybie ścisłym allow-always nadal może utrwalać nieszkodliwe wywołania interpretera/skryptu, ale nośniki inline eval nie są utrwalane automatycznie.

# Bezpieczne binaria a allowlista

Temat	tools.exec.safeBins	Allowlista (exec-approvals.json)
Cel	Automatyczne zezwalanie na wąskie filtry stdin	Jawne zaufanie konkretnym plikom wykonywalnym
Typ dopasowania	Nazwa pliku wykonywalnego + polityka argv bezpiecznego binarium	Glob rozwiązanej ścieżki pliku wykonywalnego lub glob samej nazwy polecenia dla poleceń wywoływanych przez PATH
Zakres argumentów	Ograniczony przez profil bezpiecznego binarium i reguły tokenów literalnych	Domyślnie dopasowanie ścieżki; opcjonalne argPattern może ograniczyć sparsowane argv
Typowe przykłady	head, tail, tr, wc	jq, python3, node, ffmpeg, niestandardowe CLI
Najlepsze użycie	Niskiego ryzyka transformacje tekstu w potokach	Dowolne narzędzie o szerszym zachowaniu lub skutkach ubocznych

Lokalizacja konfiguracji:

• safeBins pochodzi z konfiguracji (tools.exec.safeBins lub per agent agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs pochodzi z konfiguracji (tools.exec.safeBinTrustedDirs lub per agent agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles pochodzi z konfiguracji (tools.exec.safeBinProfiles lub per agent agents.list[].tools.exec.safeBinProfiles). Klucze profili per agent zastępują klucze globalne.
• Wpisy allowlisty znajdują się w lokalnym dla hosta ~/.openclaw/exec-approvals.json pod agents.<id>.allowlist (lub przez Control UI / openclaw approvals allowlist ...).
• openclaw security audit ostrzega przez tools.exec.safe_bins_interpreter_unprofiled, gdy binaria interpreterów/środowisk uruchomieniowych występują w safeBins bez jawnych profili.
• openclaw doctor --fix może utworzyć szkielet brakujących niestandardowych wpisów safeBinProfiles.<bin> jako {} (potem przejrzyj i zaostrz). Binaria interpreterów/środowisk uruchomieniowych nie są automatycznie szkicowane.

Przykład niestandardowego profilu: OC_I18N_900000 Jeśli jawnie dodasz jq do safeBins, OpenClaw nadal odrzuca wbudowane env w trybie bezpiecznego binarium, więc jq -n env nie może zrzucić środowiska procesu hosta bez jawnej ścieżki allowlisty lub monitu o zatwierdzenie.

# Polecenia interpreterów/środowisk uruchomieniowych

Uruchomienia interpreterów/środowisk uruchomieniowych wspierane zatwierdzeniami są celowo konserwatywne:

• Dokładny kontekst argv/cwd/env jest zawsze wiązany.
• Bezpośrednie formy skryptów powłoki i bezpośrednie formy plików środowiska uruchomieniowego są w miarę możliwości wiązane z jedną konkretną migawką pliku lokalnego.
• Typowe formy wrapperów menedżerów pakietów, które nadal rozwiązują się do jednego bezpośredniego pliku lokalnego (na przykład pnpm exec, pnpm node, npm exec, npx), są rozwijane przed wiązaniem.
• Jeśli OpenClaw nie może zidentyfikować dokładnie jednego konkretnego pliku lokalnego dla polecenia interpretera/środowiska uruchomieniowego (na przykład skrypty pakietów, formy eval, łańcuchy loaderów specyficzne dla środowiska uruchomieniowego lub niejednoznaczne formy wieloplikowe), wykonanie wspierane zatwierdzeniem jest odrzucane zamiast deklarowania pokrycia semantycznego, którego nie ma.
• Dla tych przepływów preferuj sandboxing, osobną granicę hosta albo jawnie zaufaną allowlistę/pełny przepływ pracy, w którym operator akceptuje szerszą semantykę środowiska uruchomieniowego.

Gdy zatwierdzenia są wymagane, narzędzie exec zwraca wynik natychmiast z identyfikatorem zatwierdzenia. Użyj tego identyfikatora, aby skorelować późniejsze zdarzenia systemowe (Exec finished / Exec denied). Jeśli żadna decyzja nie nadejdzie przed limitem czasu, żądanie jest traktowane jako timeout zatwierdzenia i prezentowane jako powód odmowy.

# Zachowanie dostarczania odpowiedzi uzupełniającej

Po zakończeniu zatwierdzonego asynchronicznego exec OpenClaw wysyła uzupełniający turn agent do tej samej sesji.

• Jeśli istnieje prawidłowy zewnętrzny cel dostarczania (kanał z możliwością dostarczenia plus docelowe to), dostarczanie uzupełniające używa tego kanału.
• W przepływach tylko webchat lub sesji wewnętrznych bez zewnętrznego celu dostarczanie uzupełniające pozostaje tylko sesyjne (deliver: false).
• Jeśli wywołujący jawnie żąda ścisłego dostarczania zewnętrznego bez rozwiązywalnego kanału zewnętrznego, żądanie kończy się błędem INVALID_REQUEST.
• Jeśli bestEffortDeliver jest włączone i nie można rozwiązać kanału zewnętrznego, dostarczanie jest obniżane do tylko sesyjnego zamiast kończyć się błędem.

# Przekazywanie zatwierdzeń do kanałów czatu

Możesz przekazywać monity zatwierdzeń exec do dowolnego kanału czatu (w tym kanałów pluginów) i zatwierdzać je przez /approve. Używa to zwykłego potoku dostarczania wychodzącego.

Konfiguracja: OC_I18N_900001 Odpowiedz na czacie: OC_I18N_900002 Polecenie /approve obsługuje zarówno zatwierdzenia exec, jak i zatwierdzenia pluginów. Jeśli ID nie pasuje do oczekującego zatwierdzenia exec, automatycznie sprawdza zamiast tego zatwierdzenia pluginów.

# Przekazywanie zatwierdzeń pluginów

Przekazywanie zatwierdzeń pluginów używa tego samego potoku dostarczania co zatwierdzenia exec, ale ma własną niezależną konfigurację pod approvals.plugin. Włączenie lub wyłączenie jednego nie wpływa na drugie. OC_I18N_900003 Kształt konfiguracji jest identyczny jak approvals.exec: enabled, mode, agentFilter, sessionFilter i targets działają tak samo.

Kanały obsługujące współdzielone interaktywne odpowiedzi renderują te same przyciski zatwierdzania zarówno dla zatwierdzeń exec, jak i pluginów. Kanały bez współdzielonego interaktywnego UI wracają do zwykłego tekstu z instrukcjami /approve. Żądania zatwierdzeń pluginów mogą ograniczać dostępne decyzje. Powierzchnie zatwierdzania używają zadeklarowanego zestawu decyzji żądania, a Gateway odrzuca próby przesłania decyzji, która nie została zaoferowana.

# Zatwierdzenia w tym samym czacie na dowolnym kanale

Gdy żądanie zatwierdzenia exec lub pluginu pochodzi z dostarczalnej powierzchni czatu, ten sam czat może teraz domyślnie zatwierdzić je przez /approve. Dotyczy to kanałów takich jak Slack, Matrix i Microsoft Teams oprócz istniejących przepływów Web UI i terminal UI.

Ta współdzielona ścieżka polecenia tekstowego używa zwykłego modelu autoryzacji kanału dla tej rozmowy. Jeśli czat źródłowy może już wysyłać polecenia i odbierać odpowiedzi, żądania zatwierdzenia nie potrzebują już osobnego natywnego adaptera dostarczania tylko po to, aby pozostać oczekujące.

Discord i Telegram również obsługują /approve w tym samym czacie, ale te kanały nadal używają swojej rozwiązanej listy zatwierdzających do autoryzacji nawet wtedy, gdy natywne dostarczanie zatwierdzeń jest wyłączone.

Dla Telegram i innych natywnych klientów zatwierdzania, które wywołują Gateway bezpośrednio, ten fallback jest celowo ograniczony do niepowodzeń „nie znaleziono zatwierdzenia”. Rzeczywista odmowa/błąd zatwierdzenia exec nie ponawia po cichu próby jako zatwierdzenie pluginu.

# Natywne dostarczanie zatwierdzeń

Niektóre kanały mogą również działać jako natywni klienci zatwierdzania. Natywni klienci dodają wiadomości DM do zatwierdzających, rozsyłanie do czatu źródłowego oraz specyficzny dla kanału interaktywny interfejs zatwierdzania UX ponad współdzielony przepływ /approve w tym samym czacie.

Gdy dostępne są natywne karty/przyciski zatwierdzania, ten natywny interfejs UI jest główną ścieżką widoczną dla agenta. Agent nie powinien dodatkowo powielać zwykłego polecenia czatu /approve, chyba że wynik narzędzia mówi, że zatwierdzenia przez czat są niedostępne albo ręczne zatwierdzenie jest jedyną pozostałą ścieżką.

Jeśli skonfigurowano natywnego klienta zatwierdzania, ale dla kanału źródłowego nie jest aktywne żadne natywne środowisko uruchomieniowe, OpenClaw pozostawia widoczny lokalny deterministyczny monit /approve. Jeśli natywne środowisko uruchomieniowe jest aktywne i próbuje dostarczyć kartę, ale żaden cel jej nie otrzyma, OpenClaw wysyła w tym samym czacie powiadomienie awaryjne z dokładnym poleceniem /approve <id> <decision>, aby żądanie nadal można było rozwiązać.

Model ogólny:

• zasada wykonywania hosta nadal decyduje, czy wymagane jest zatwierdzenie wykonywania
• approvals.exec steruje przekazywaniem monitów zatwierdzania do innych miejsc docelowych czatu
• channels.<channel>.execApprovals steruje tym, czy dany kanał działa jako natywny klient zatwierdzania

Natywni klienci zatwierdzania automatycznie włączają dostarczanie najpierw przez DM, gdy spełnione są wszystkie te warunki:

• kanał obsługuje natywne dostarczanie zatwierdzeń
• zatwierdzających można rozpoznać z jawnych execApprovals.approvers lub tożsamości właściciela, takiej jak commands.ownerAllowFrom
• channels.<channel>.execApprovals.enabled nie jest ustawione albo ma wartość "auto"

Ustaw enabled: false, aby jawnie wyłączyć natywnego klienta zatwierdzania. Ustaw enabled: true, aby wymusić jego włączenie, gdy zatwierdzający zostaną rozpoznani. Publiczne dostarczanie do czatu źródłowego pozostaje jawne przez channels.<channel>.execApprovals.target.

FAQ: Dlaczego istnieją dwie konfiguracje zatwierdzeń wykonywania dla zatwierdzeń przez czat?

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*

Ci natywni klienci zatwierdzania dodają kierowanie przez DM i opcjonalne rozsyłanie do kanału ponad współdzielony przepływ /approve w tym samym czacie oraz współdzielone przyciski zatwierdzania.

Współdzielone zachowanie:

• Slack, Matrix, Microsoft Teams i podobne czaty z możliwością dostarczania używają normalnego modelu autoryzacji kanału dla /approve w tym samym czacie
• gdy natywny klient zatwierdzania włącza się automatycznie, domyślnym natywnym celem dostarczania są wiadomości DM do zatwierdzających
• w Discord i Telegram tylko rozpoznani zatwierdzający mogą zatwierdzać lub odmawiać
• zatwierdzający w Discord mogą być jawni (execApprovals.approvers) albo wywnioskowani z commands.ownerAllowFrom
• zatwierdzający w Telegram mogą być jawni (execApprovals.approvers) albo wywnioskowani z commands.ownerAllowFrom
• zatwierdzający w Slack mogą być jawni (execApprovals.approvers) albo wywnioskowani z commands.ownerAllowFrom
• natywne przyciski Slack zachowują rodzaj identyfikatora zatwierdzenia, więc identyfikatory plugin: mogą rozwiązywać zatwierdzenia pluginu bez drugiej lokalnej warstwy awaryjnej Slack
• natywne kierowanie DM/kanału w Matrix i skróty reakcji obsługują zarówno zatwierdzenia wykonywania, jak i pluginu; autoryzacja pluginu nadal pochodzi z channels.matrix.dm.allowFrom
• natywne monity Matrix zawierają niestandardową treść zdarzenia com.openclaw.approval w pierwszym zdarzeniu monitu, aby klienci Matrix świadomi OpenClaw mogli odczytać ustrukturyzowany stan zatwierdzenia, podczas gdy standardowi klienci zachowują zwykły tekst awaryjny /approve
• osoba żądająca nie musi być zatwierdzającym
• czat źródłowy może zatwierdzać bezpośrednio przez /approve, gdy ten czat już obsługuje polecenia i odpowiedzi
• natywne przyciski zatwierdzania Discord kierują według rodzaju identyfikatora zatwierdzenia: identyfikatory plugin: trafiają bezpośrednio do zatwierdzeń pluginu, a wszystko inne trafia do zatwierdzeń wykonywania
• natywne przyciski zatwierdzania Telegram stosują ten sam ograniczony awaryjny przepływ od wykonywania do pluginu co /approve
• gdy natywne target włącza dostarczanie do czatu źródłowego, monity zatwierdzania zawierają tekst polecenia
• oczekujące zatwierdzenia wykonywania domyślnie wygasają po 30 minutach
• jeśli żaden interfejs operatora ani skonfigurowany klient zatwierdzania nie może przyjąć żądania, monit wraca awaryjnie do askFallback

Wrażliwe polecenia grupowe przeznaczone tylko dla właściciela, takie jak /diagnostics i /export-trajectory, używają prywatnego kierowania właściciela dla monitów zatwierdzania i końcowych wyników. OpenClaw najpierw próbuje użyć prywatnej trasy na tej samej powierzchni, na której właściciel uruchomił polecenie. Jeśli ta powierzchnia nie ma prywatnej trasy właściciela, przełącza się na pierwszą dostępną trasę właściciela z commands.ownerAllowFrom, dzięki czemu polecenie grupowe Discord nadal może wysłać zatwierdzenie i wynik do DM właściciela w Telegram, gdy Telegram jest skonfigurowanym głównym interfejsem prywatnym. Czat grupowy otrzymuje tylko krótkie potwierdzenie.

Telegram domyślnie używa wiadomości DM do zatwierdzających (target: "dm"). Możesz przełączyć na channel albo both, gdy chcesz, aby monity zatwierdzania pojawiały się również w źródłowym czacie/temacie Telegram. W przypadku tematów forum Telegram OpenClaw zachowuje temat dla monitu zatwierdzania i dalszej wiadomości po zatwierdzeniu.

Zobacz:

• Discord
• Telegram

# Przepływ IPC w macOS

OC_I18N_900004 Uwagi dotyczące bezpieczeństwa:

• Tryb gniazda Unix 0600, token przechowywany w exec-approvals.json.
• Sprawdzenie peera o tym samym UID.
• Wyzwanie/odpowiedź (nonce + token HMAC + hash żądania) + krótki TTL.

# Powiązane

• Zatwierdzenia wykonywania — główna zasada i przepływ zatwierdzania
• Narzędzie exec
• Tryb podwyższony
• Skills — zachowanie automatycznego zezwalania oparte na skillach