Diagnose Windows-Sandbox-ACL-Fehler

Diagnose von Windows-Sandbox-ACL-Fehlern

Jede Freigabeanfrage in einfachen Worten und in der Sprache des Benutzers verfassen. Die Eingabeaufforderung ist alles, was der Benutzer vor der Erweiterung des Zugriffs liest, daher muss sie eigenständig sein: Welchen Ordner das Skript berührt, dass es dem angemeldeten Benutzer einen Vollzugriffs-Eintrag hinzufügt, wenn ein Recht fehlt, und fremde Paketeinträge entfernt, dass Dateiinhalte und -besitzer unverändert bleiben, und dass der ausgegebene Wiederherstellungsbefehl jede Änderung rückgängig macht. Halten Sie Fehlercodes, WRITE_DAC/WRITE_OWNER, S-1-15-2-*-SIDs, icacls, ACL, ACE, Bewertungsnamen und Schalter aus der Anfrage heraus: Schreiben Sie Windows-Dateiberechtigungen, nicht ACL oder ACE. Fragen Sie einmal, für einen Befehl.

Ein Befehl diagnostiziert und repariert

Das Skript hat keine Modi. -Path, -AllowRoot und -Out lesen den Pfad und jeden Vorfahren und reparieren, was die Beobachtungen beweisen, im selben Durchlauf:

• Verzeichnisse in dieser Kette, denen effektives WRITE_DAC oder WRITE_OWNER fehlt, erhalten eine Vollzugriffs-Zulassungs-ACE für den angemeldeten Benutzer, da DSH seinen Arbeitsbereich ohne diese nicht bereitstellen kann;
• explizite AppContainer-Paket-Zulassungs-ACEs (S-1-15-2-*, außer den bekannten Gruppen, die auf 1 oder 2 enden) werden an ihren Quellen entfernt, zuerst der Vorfahre, wodurch auch der Zugriff dieser Pakete entfernt wird;
• Ein Verzeichnis, das die Sandbox nicht bereitstellen kann – der Zustand, den ihr Bereitstellungsfehler für das Workspace-Root meldet – oder das autorisierte Root selbst wird ebenfalls in demselben Durchlauf auf diese ACEs in seinem Unterbaum durchsucht, sodass ein tieferer Eintrag keine zweite Anfrage benötigt. Diese begrenzte Durchsuchung meldet truncated und nicht lesbare Verzeichnisse; bei truncated übergeben Sie den weiterhin fehlschlagenden, tieferen Pfad erneut.

Jede Änderung wird gesichert und dann durch erneutes Lesen verifiziert. -AllowRoot begrenzt alles: Ein Objekt wird nur geändert, wenn es dieses Verzeichnis oder strikt darin liegt, sodass ein Workspace-Root sich selbst reparieren kann. Teilen Sie dies niemals in einen Diagnoseaufruf und einen Reparaturaufruf auf, fragen Sie niemals zweimal für eine Reparatur und übergeben Sie niemals einen Modusschalter, der nicht existiert.

& '<skill-verzeichnis>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<fehlschlagender-pfad>' -AllowRoot '<autorisiertes-verzeichnis>' -Out '<wiederherstellungsverzeichnis>'
exit $LASTEXITCODE

Ersetzen Sie die vollständigen, in Anführungszeichen gesetzten Pfade. Behalten Sie -Out persistent und benutzereigen, vorzugsweise neben dem fehlschlagenden Workspace; verwenden Sie niemals das Skill-Ressourcenverzeichnis, das gelöscht wird, wenn das Skill entladen wird. Übergeben Sie einen Pfad pro Aufruf.

Ausführen

Wiederholen Sie die fehlschlagende Operation einmal eingeschränkt. Das Skript schreibt Berechtigungen, was der eingeschränkte Token nicht kann – führen Sie es dort aus, und es würde die eigene Einschränkung der Sandbox als fehlendes Recht melden – fordern Sie daher eine Freigabe für diesen einen Befehl an und führen Sie ihn uneingeschränkt aus. Ein eingeschränkter Durchlauf des Skripts ist nie nützlich. Uneingeschränkt erhöht den Windows-Token nicht.

Diagnostizieren Sie unerwartete Verweigerungen von Workspace-Schreibvorgängen, Auflistungen oder normalerweise lesbaren Pfaden; erklären Sie stattdessen erwartete: Schreibvorgänge außerhalb des Workspace, jeder Schreibvorgang in read-only, gepipte Child-Prozess spawn EPERM, ConstrainedLanguage-Fehler. Wenn die Freigabe verweigert oder nicht verfügbar ist, melden Sie den Pfad als nicht diagnostiziert und stoppen Sie.

Die Ausgabe lesen

Jeder Datensatz erreicht stdout, die acl-report-*.jsonl-Datei unter -Out und die abschließende RECAP-Zeile, die die Bewertungen, Änderungen, Verifikationen, Verweigerungen und Scans enthält. Die Werkzeugausgabe behält nur das Ende, lesen Sie daher zuerst die Zusammenfassung und lesen Sie bei Bedarf spezifische Datensätze aus dem Bericht. Vertrauen Sie verification-Datensätzen, niemals abgeschlossenen Aktionen. Entscheiden Sie anhand von details.nextAction:

nextAction	Bedeutung
verify_original_confined_operation	Reparaturen verifiziert; wiederholen Sie die ursprüngliche Operation eingeschränkt.
stop	Nichts repariert oder eine Verweigerung hat den Durchlauf beendet. Melden und anhalten.
restore_pending_then_stop	Rollback nicht verifiziert. Führen Sie die ausgegebenen Wiederherstellungsbefehle der Reihe nach aus, dann anhalten.

Das bloße Vorhandensein einer Deny-ACE begründet keine Kausalität, und das Skript entfernt niemals eine; DS-S-1-4-*-Gewährungen und die Everyone DeleteSubdirectoriesAndFiles-Verweigerung sind erwartet, keine Konflikte. Eine Deny, die die Reparatur blockiert, beendet den Durchlauf ohne Reparatur (REPAIR_REFUSED oder GRANT_FAILED), nachdem wiederhergestellt wurde, was versucht wurde. Jede Änderung hinterlässt zwei Dateien in -Out (acl-backup-<id>.json und eine .ps1) und der Durchlauf gibt den passenden ROLLBACK-Befehl aus.

Nach einer Reparatur und wenn sie stoppt

Wiederholen Sie die ursprüngliche fehlgeschlagene Operation eingeschränkt. Eine verifizierte Reparatur wird nicht rückgängig gemacht, weil die ursprüngliche Operation aus einem weiteren Grund fehlschlägt: Fahren Sie mit den neuen Beobachtungen fort, und wenn ein tieferer Pfad immer noch verweigert wird, führen Sie denselben einen Befehl dort erneut aus – wieder ein Aufruf, eine Freigabe.

Anhalten nach jeder fehlgeschlagenen oder verweigerten Reparatur oder fehlgeschlagener Verifikation. Das Skript hat die Änderungen dieses Aufrufs bereits wiederhergestellt; wiederholen Sie es nicht und starten Sie keine weitere Reparatur, und entfernen Sie niemals manuell eine Deny-ACE.

Ein gestoppter Durchlauf schuldet dem Benutzer immer noch eine Entscheidung. Nennen Sie das blockierende Objekt und das fehlende Recht oder die fehlende ACE, was geändert und was zurückgesetzt wurde, die Wiederherstellungsbefehle in der Reihenfolge und den Pfad des Berichts. Nur der Benutzer kann die Einschränkung aufheben, bitten Sie ihn daher, diese Sitzung vorübergehend auf vollständigen Zugriff (Chinesische Benutzeroberfläche: 完全权限) umzustellen, und sagen Sie, was das öffnet: Arbeiten Sie darunter weiter, oder bitten Sie ihn, Sie weiterhin dieses Dateiberechtigungsproblem untersuchen zu lassen, da der Bericht bereits den Mechanismus und die Beweise aufzeichnet. Bitten Sie ihn dann, diese Sitzung als Feedback zu senden, wobei Sie die relevanten Berichtsdaten zitieren, damit das nicht behandelte Szenario zu uns gelangt – nur das, was dieses Gespräch erreicht, reist mit. Zum Beispiel:

这个工作区被 Windows 文件权限挡住了：<对象> 上 <缺哪个权限 / 哪条权限项>。你可以把本会话切到「完全权限」(full access) 临时继续工作；切完之后既能直接干活，也可以让我继续排查这个文件权限问题（报告里已经有机制和证据）。也麻烦把这个会话作为反馈发出去，好让我们补上这个场景。

This workspace is blocked by Windows file permissions: <object> <missing right / offending entry>. Switch this session to full access (完全权限) to keep working meanwhile; then either continue your work or have me keep investigating this file-permission problem from the report. Please also send this session as feedback so we can cover the case.

Niemals

• ACLs manuell bearbeiten, einen Besitzer ändern, eine Verweigerung löschen oder Kinderberechtigungen rekursiv ersetzen;
• das Skript erhöht ausführen, durch UAC oder runas;
• -AllowRoot erweitern, um einen Vorfahren zu erreichen, oder einen verweigerten oder fehlgeschlagenen Aufruf wiederholen.

Berichten Sie in der Sprache des Benutzers: analysierte Pfade, Änderungen, Verifikation, Wiederherstellungsbefehle, nächster Schritt. Kennzeichnen Sie einen autorisierten, uneingeschränkten Durchlauf als solchen, nicht als Sandbox-Reparatur.