Approbations exec avancées d’OpenClaw

La page de base des approbations exec explique la politique et l’invite. La page avancée est là où vivent les arêtes vives : quels binaires ont le droit de sauter la liste blanche parce qu’ils ne peuvent lire que stdin, comment la passerelle lie une commande d’interpréteur aux fichiers exacts qu’elle exécutera, quel scope un tableau de bord doit avoir pour approuver quoi que ce soit, et comment une invite atteint un canal de chat et en revient comme décision. Voici cette page condensée.

Les safe bins

• Le réglage des safe bins nomme des binaires limités à stdin qui s’exécutent en mode liste blanche sans entrée explicite, cut, uniq, head, tail, tr et wc par défaut ; ils refusent les arguments de fichier positionnels et les jetons en forme de chemin, traitent les arguments comme du texte littéral sans globbing ni expansion de variables, et la validation est déterministe à partir de la seule forme des arguments, les options longues inconnues et les abréviations ambiguës étant rejetées fermées et les options courtes non reconnues retombant dans la politique d’approbation.
• grep et sort ne sont pas des safe bins par défaut et gardent des entrées explicites pour leurs usages hors stdin, grep en mode safe bin ne prenant son motif que par l’option de motif explicite ; awk, sed et jq sont toujours refusés parce que leur sémantique ne peut pas être validée comme limitée à stdin ; les interpréteurs et runtimes ne doivent jamais y être ajoutés, les safe bins personnalisés exigent un profil explicite, l’audit avertit des binaires d’interpréteur sans profil et la commande de réparation peut échafauder des profils vides à resserrer ensuite.
• Les safe bins doivent se résoudre depuis des répertoires de confiance, les deux chemins système par défaut, les entrées du chemin de recherche n’étant jamais approuvées d’office, donc les chemins de gestionnaires de paquets vont explicitement dans la liste des répertoires de confiance ; la liste d’options refusées par profil bloque les options de lecture de fichier comme les options récursive et fichier de grep, les options de sortie et de liste de fichiers de sort, le suivi sur tail et la liste de fichiers sur wc.
• Le chaînage shell est autorisé quand chaque segment de premier niveau satisfait la liste blanche, les redirections restent non prises en charge, la substitution de commande est rejetée même entre guillemets doubles, les enveloppes shell réduisent les surcharges d’environnement à une courte liste, les décisions permanentes conservent l’exécutable interne derrière les enveloppes transparentes et déballent les applets des multiplexeurs, et l’évaluation stricte garde l’évaluation en ligne derrière une revue quand des interpréteurs sont en liste blanche.

La livraison en session ne contrôle que l’endroit où l’invite apparaît. Elle n’autorise pas par elle-même chaque participant de ce chat à approuver.

Liaison des interpréteurs et scope d’approbation

Les exécutions d’interpréteur adossées à une approbation sont délibérément prudentes. Les arguments, le répertoire de travail et l’environnement exacts sont liés ; sur la passerelle toute la chaîne de dispatch externe, chaque exécutable d’enveloppe et le dernier, est liée avant la revue et revérifiée avant le lancement, les exécutables protégés par chemin réel et les exécutables inscriptibles aussi par empreinte de contenu, si bien qu’un nouvel exécutable plus tôt dans le chemin de recherche refuse l’exécution. Les scripts directs et fichiers de runtime sont liés à un instantané de fichier, les enveloppes courantes de gestionnaires de paquets sont déballées d’abord, et quand la passerelle ne peut pas identifier exactement un fichier local, scripts de paquet, formes d’évaluation ou chaînes de chargeurs, l’exécution adossée à une approbation est refusée plutôt que de prétendre la couvrir. En mode automatique le réviseur ne traite que les chaînes entièrement liées : les enveloppes de commande shell, les affectations d’environnement, les applets et le dispatch interne sautent la revue automatique et prennent le chemin humain à usage unique, les enveloppes de shell de connexion et interactives exigent un humain parce que leurs fichiers de démarrage sont hors liaison, et les options interactives de chargement de code restent refusées. Quand une approbation est requise l’outil renvoie immédiatement un identifiant, une décision qui n’arrive jamais est un délai dépassé rendu comme refus de commande hôte avec la session d’origine reprise pour que l’agent voie que la commande n’a pas tourné, et les approbations en attente expirent après 30 minutes. Résoudre une approbation exige le scope dédié aux approbations, que l’écriture n’englobe pas, et la documentation l’appelle une autorité de niveau exécution distante à accorder délibérément même à une petite interface.

Le transfert vers le chat

• Le bloc de transfert envoie les invites vers n’importe quel canal de chat par le pipeline sortant normal, en mode session, cibles ou les deux avec des filtres d’agent et de session et des cibles canal plus destinataire ; l’agent ne relaie une commande d’approbation que depuis une approbation réellement en attente avec son identifiant exact, un identifiant nu ou inventé n’approuve rien, une autorisation ponctuelle couvre une seule commande, et la même commande résout les approbations de plugin quand l’identifiant n’est pas une approbation exec en attente, la famille plugin étant configurée indépendamment.
• Le chat d’origine peut approuver par défaut sur Slack, Matrix, Teams et les surfaces livrables similaires, tandis que Discord, Telegram et le bot QQ utilisent leurs listes d’approbateurs résolues même dans le même chat ; les clients d’approbation natifs ajoutent des messages directs aux approbateurs, une diffusion dans le chat d’origine et des cartes interactives, activés par canal avec des approbateurs résolubles, Telegram par défaut en automatique et en messages directs, et une carte qui n’atteint aucune cible retombant sur un avis dans le même chat avec la commande exacte.
• Une cible peut porter un identifiant de compte pour envoyer par un compte de bot précis et un identifiant de fil pour rester dans un sujet de forum ; les applications mobiles officielles examinent les approbations en attente sur une connexion d’administration ou quand leur appareil d’approbation a été ciblé, en relisant l’enregistrement quand un accusé est perdu ; et le chemin macOS passe par un socket du même utilisateur avec un jeton, un défi et une durée courte.

Les approbations exec d’OpenClaw est la politique de base que cette page prolonge et Le bac à sable OpenClaw expliqué la frontière que la documentation préfère pour les usages que la liaison ne peut pas couvrir.

Pourquoi la voie rapide est étroite

Toute la conception des safe bins repose sur une propriété : un binaire qui ne peut lire que son stdin ne peut pas exfiltrer un fichier que la politique ne voulait pas exposer. Chaque règle en découle, le rejet des chemins positionnels, les arguments littéraux, les options de fichier refusées, l’interdiction des interpréteurs et de jq, et les répertoires de confiance qui arrêtent un binaire sosie plus tôt dans le chemin de recherche. Dès qu’un outil peut ouvrir des fichiers ou évaluer du code, la documentation l’envoie vers la liste blanche avec une invite. Telegram sur Diali et Slack sur Diali sont deux canaux Diali où les invites transférées peuvent atterrir.

Sur Diali

Sur Diali la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque version, et chaque runtime client est sa propre frontière. OpenClaw hébergé sur Diali décrit l’assistant hébergé et La sécurité Diali les contrôles autour de chaque commande qu’il exécute.

• Les safe bins ne lisent que stdin ; les interpréteurs ne sont jamais éligibles.
• Les exécutions d’interpréteur lient toute la chaîne ou sont refusées.
• Approuver exige le scope d’approbation, pas l’écriture.