Berechtigungen und Prozesssicherheit

Verschiedene Grenzen nicht verwechseln

Eine Freigabe gilt für den geprüften Vorgang und Geltungsbereich, nicht automatisch für ähnliche Befehle, andere Arbeitsverzeichnisse oder geänderte Skripte. Der Zugriff auf Secrets benötigt eine ausdrückliche Freigabe der betroffenen Datei; ein allgemeiner Auftrag wie „Projekt analysieren“ genügt nicht.

Einmal, Sitzung und persistent

Der Permissiondialog kann je nach Capability und Schutzgate einmalige, Sitzungs- oder erinnerbare Freigaben anbieten. Nicht jeder Vorgang darf dauerhaft freigegeben werden. Quelle, aufgelöste Programmidentität, argv, CWD, Pfade und Inhaltsbindung können entscheidend sein. Eine Ablehnung ist zu respektieren – kein Werkzeugwechsel oder Wrapper nur zur Umgehung.

/permissions zeigt Sitzungsfreigaben, Settingsregeln und dauerhafte Projektberechtigungen mit IDs und Geltungsbereich. Ältere inaktive Freigaben sind davon zu unterscheiden. Einstellungen erklärt, warum JSON-Einträge allein noch keine Zustimmung sind.

Drei unterschiedliche Regelarten

Toolmuster

permissions.allow und deny akzeptieren Tool oder Tool(pattern); der allgemeine Matcher unterstützt *, **, ?. Eine Toolregel ist nicht dieselbe Syntax wie allowedCommands. Allow ersetzt keine Secret-, Dangerous-, Pfad- oder Capabilitygates. Globale Denys werden sofort angewandt, Projektdenys ergänzen sie.

Bashlisten

Projektbeispiel .lurus/settings.json:

{
  "permissions": {
    "allow": [],
    "deny": [],
    "allowedCommands": ["git status"],
    "deniedCommands": ["git push"],
    "bashAutoApprove": false
  }
}

Globales Gegenstück: dieselbe Struktur in ~/.lurus/settings.json, nach bewusstem globalen Consent. Erwartung: enges Angebot für git status, kein pauschales Gitrecht.

allowedCommands muss den vollständigen Befehl exakt treffen. deniedCommands trifft entweder exakt oder als Präfix mit folgendem Leerzeichen. Freigabewildcards werden nicht unterstützt. bashAutoApprove steuert die Freigabe sicher eingestufter Bashbefehle, nicht sämtlicher Prozesse. Verlassen Sie sich nicht auf einen einheitlichen Standardwert. Ein genehmigtes globales true kann einen Projektwert false überstimmen; setzen Sie den gewünschten sicheren Zustand ausdrücklich global.

Strukturierter Exec

Exec startet ein Programm mit argv-Array und geprüftem CWD, ohne Shellinterpretation. Bevorzugen Sie Exec für normale Builds und Tests. Argumente mit Leerzeichen, &, | oder $() sind als Arrayelemente nicht automatisch Shellsyntax; ein explizit aufgerufener Interpreter kann sie trotzdem ausführen.

Ein Grant kann an konkrete Executableidentität, Script-/Lifecycleinhalt und Projekt-CWD gebunden sein. npm run lint kann pre/post-Scripts ausführen; lokale Programme und npx können zusätzliche oder nichtpersistierbare Prüfungen brauchen. Freigabe eines Programmnamens ist keine universelle Sicherheit.

Beispielablauf für ein vorhandenes geprüftes npm-Skript:

1. package.json einschließlich lint, prelint, postlint lesen.
2. Hauptagent explizit bitten, dieses Skript im Projekt auszuführen.
3. Permissiondialog mit Programm, argv und CWD prüfen; nur angebotenen engen Grant speichern.
4. /permissions zeigt Quelle und ID.
5. Script ändern oder CWD wechseln: erneute Prüfung kann nötig sein.
6. Den betreffenden Grant mit der angezeigten ID widerrufen.

Keine Helper-/Wrapperdatei erstellen, um eine verweigerte Operation unter anderem Namen freizuschalten. Bash nur für tatsächlich benötigte Shellzusammensetzung.

Vollständiger Widerruf

Verwenden Sie IDs aus Ihrer tatsächlichen /permissions-Ausgabe; <id> ist nur ein Platzhalter.

Achtung: Diese Befehle widerrufen Freigaben. revoke <id> entfernt eine dauerhafte Projektfreigabe ohne weiteren Dialog; clear entfernt die dauerhaften Projektfreigaben. Prüfen Sie vorher Quelle und Geltungsbereich.

/permissions
/permissions revoke <id>
/permissions revoke session <id>
/permissions revoke settings <id>
/permissions revoke global-settings
/permissions clear

Die ursprüngliche Settingsregel gegebenenfalls bewusst bearbeiten, damit sie nach neuer Zustimmung nicht erneut aktiv wird. Umfang der clear-/revokeaktion vor Verwendung prüfen.

Beschädigte Stores reparieren

Achtung: Diese Reparatur betrifft gespeicherte Berechtigungen beziehungsweise Freigaben für alle Projekte. Verwenden Sie sie nur bei beschädigten Daten, nicht für alltägliche Bereinigung. Die beschädigten Daten werden gesichert; die Bestätigung ist mit Nein vorbelegt.

/permissions repair
/permissions repair trust

Gültige Stores werden nicht allgemein zurückgesetzt. Löschen Sie die Dateien nicht von Hand. Prüfen Sie bei Problemen die genaue Warnung und betroffene Quelle, ohne Zugangsdaten zu veröffentlichen.

Gefährlicher Trust und Automation

Gefahr: /trust on deaktiviert die Freigabeprüfungen für die Sitzung. Das kann unkontrollierte Befehle und Dateiänderungen ermöglichen und ist kein Ersatz für enge Freigaben. Der globale Wert "disableDangerousTrust": true sperrt diese Funktion.

/trust
/trust on
/trust off

/trust zeigt den Status. Zum Aktivieren müssen Sie exakt I understand the risks bestätigen. /trust off stellt die Freigabeprüfungen sofort wieder her. Der Startparameter --permission-mode dangerouslySkipAllPermissions deaktiviert sie ebenfalls, sofern nicht global gesperrt, aber ohne diesen interaktiven Phrasendialog. Verwenden Sie ihn nicht als Einsteiger- oder Automationsstandard.

Batch und Einzelprompts entscheiden ohne interaktive Eingabe. Aktionen, die besondere Freigaben für Secrets, gefährliche Vorgänge oder geschützte Einstellungen benötigen, werden abgelehnt; andere können einmalig freigegeben werden. Das ist kein umfassender Schreibschutz. LURUS_AUTO_CONSENT kann die Zustimmung für Einstellungen, Hooks und MCP automatisieren und ist nur für bewusst vertrauenswürdige Eingaben geeignet.

Kindprozesse erhalten eine feste Liste zugelassener Umgebungsvariablen, nicht automatisch API-Schlüssel oder Tokens. LURUS_BASH_PASS_ENV, LURUS_HOOK_PASS_ENV und LURUS_MCP_PASS_ENV ergänzen kommaseparierte Namen. Jeder zusätzlich freigegebene Wert ist für den Kindprozess vollständig sichtbar.