Diagnostiquer les échecs ACL du sandbox Windows
Formulez chaque demande d'approbation en langage simple, dans la langue de l'utilisateur. Le prompt est tout ce que l'utilisateur lit avant d'élargir l'accès, il doit donc être autonome : indiquez quel dossier le script touche, qu'il ajoute l'entrée de contrôle total pour l'utilisateur connecté là où un droit manque et supprime les entrées de package étrangères, que le contenu des fichiers et les propriétaires restent inchangés, et que la commande de restauration annule chaque modification. Évitez les codes d'erreur, WRITE_DAC/WRITE_OWNER, les SID S-1-15-2-*, icacls, ACL, ACE, les noms de verdict et les commutateurs dans la demande : écrivez « autorisations de fichiers Windows », pas ACL ou ACE. Demandez une fois, pour une seule commande.
Une commande unique diagnostique et répare
Le script n'a pas de modes. -Path, -AllowRoot et -Out lisent le chemin et chaque ancêtre et réparent ce que les observations prouvent, dans la même exécution :
- les répertoires de cette chaîne qui n'ont pas
WRITE_DACouWRITE_OWNEReffectifs reçoivent une ACE d'autorisation de contrôle total pour l'utilisateur connecté, car DSH ne peut pas provisionner son espace de travail sans eux ; - les ACE d'autorisation explicites des packages AppContainer (
S-1-15-2-*, sauf les groupes bien connus se terminant par 1 ou 2) sont supprimées à leurs sources, ancêtre en premier, ce qui supprime également l'accès de ces packages ; - un répertoire que le sandbox ne peut pas provisionner — l'état que son erreur de provisionnement signale sur la racine de l'espace de travail — ou la racine autorisée elle-même voit également sa sous-arborescence recherchée pour ces ACE lors de la même exécution, afin qu'une entrée plus profonde n'ait pas besoin d'une deuxième demande. Cette recherche bornée signale les répertoires
truncatedet illisibles ; si tronquée, passez le chemin profond toujours en échec une fois de plus.
Chaque modification est sauvegardée, puis vérifiée en la relisant. -AllowRoot borne tout : un objet n'est modifié que s'il s'agit de ce répertoire ou qu'il se trouve strictement à l'intérieur, afin qu'une racine d'espace de travail puisse se réparer elle-même. Ne divisez jamais cela en un appel de diagnostic et un appel de réparation, ne demandez jamais deux fois pour une seule réparation, et ne passez jamais un commutateur de mode qui n'existe pas.
& '<skill-directory>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<failing-path>' -AllowRoot '<authorized-directory>' -Out '<recovery-directory>'
exit $LASTEXITCODE
Remplacez par des chemins complets et entre guillemets. Gardez -Out persistant et appartenant à l'utilisateur, de préférence à côté de l'espace de travail en échec ; n'utilisez jamais le répertoire des ressources du skill, qui est supprimé lorsque le skill se décharge. Passez un chemin par invocation.
Exécution
Répétez l'opération en échec une fois en mode confiné. Le script écrit les autorisations, ce que le jeton confiné ne peut pas faire — exécutez-le là et il signalerait la propre restriction du sandbox comme un droit manquant — demandez donc l'approbation pour cette commande unique et exécutez-la en mode non confiné. Une exécution confinée du script n'est jamais utile. Le mode non confiné n'élève pas le jeton Windows.
Diagnostiquez les refus inattendus d'écriture dans l'espace de travail, de listage, ou de chemins normalement lisibles ; expliquez plutôt les refus attendus : écritures en dehors de l'espace de travail, toute écriture en mode read-only, spawn EPERM sur les processus enfants en pipeline, erreurs ConstrainedLanguage. Si l'approbation est refusée ou indisponible, signalez le chemin comme non diagnostiqué et arrêtez-vous.
Lecture de la sortie
Chaque enregistrement atteint stdout, le fichier acl-report-*.jsonl sous -Out, et la ligne RECAP finale, qui porte les verdicts, les modifications, les vérifications, les refus et les analyses. La sortie de l'outil ne conserve que sa fin, lisez donc le résumé d'abord, et lisez des enregistrements spécifiques dans le rapport lorsque cela ne suffit pas. Faites confiance aux enregistrements de type verification, jamais aux actions completed. Décidez à partir de details.nextAction :
nextAction | Signification |
|---|---|
verify_original_confined_operation | Réparations vérifiées ; répétez l'opération originale en mode confiné. |
stop | Rien réparé, ou un refus a mis fin à l'exécution. Signalez et arrêtez-vous. |
restore_pending_then_stop | Restauration en attente non vérifiée. Exécutez les commandes de restauration imprimées dans l'ordre, puis arrêtez-vous. |
La seule présence d'une ACE de refus n'établit pas de causalité, et le script n'en supprime jamais ; les autorisations S-1-4-* de DSH et le refus DeleteSubdirectoriesAndFiles pour Tout le monde sont attendus, pas des conflits. Un refus qui bloque la réparation met fin à l'exécution sans réparation (REPAIR_REFUSED, ou GRANT_FAILED) après avoir restauré ce qui a été tenté. Chaque modification laisse deux fichiers dans -Out (acl-backup-<id>.json et son .ps1), et l'exécution imprime la commande ROLLBACK correspondante.
Après une réparation, et en cas d'arrêt
Répétez l'opération originale en échec en mode confiné. Une réparation vérifiée n'est pas annulée parce que l'opération originale échoue pour une raison supplémentaire : continuez à partir des nouvelles observations, et si un chemin plus profond est toujours refusé, exécutez la même commande unique là — encore un appel, une approbation.
Arrêtez-vous après toute réparation échouée ou refusée, ou après une vérification échouée. Le script a déjà restauré les modifications de cette invocation ; ne la répétez pas et ne démarrez pas une autre réparation, et ne supprimez jamais une ACE de refus manuellement.
Une exécution arrêtée doit toujours une décision à l'utilisateur. Nommez l'objet bloquant et le droit ou l'ACE qui lui manque, ce qui a changé et ce qui a été restauré, les commandes de restauration dans l'ordre, et le chemin du rapport. Seul l'utilisateur peut lever la restriction, demandez-lui donc de passer cette session en accès total (Chinese UI: 完全权限) temporairement, et dites ce que cela ouvre : continuer à travailler sous cet accès, ou vous demander de continuer à enquêter sur ce problème d'autorisations de fichiers, puisque le rapport enregistre déjà le mécanisme et les preuves. Demandez-lui ensuite d'envoyer cette session en retour, en citant les enregistrements du rapport qui comptent, afin que le scénario non traité nous parvienne — seules les informations qui arrivent dans cette conversation voyagent avec elle. Par exemple :
这个工作区被 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.
Ne jamais
- modifier les ACL manuellement, changer un propriétaire, effacer un refus, ou remplacer récursivement les autorisations enfants ;
- exécuter le script en mode élevé, via UAC ou
runas; - élargir
-AllowRootpour atteindre un ancêtre, ou répéter un appel refusé ou échoué.
Signalez dans la langue de l'utilisateur : chemins analysés, modifications, vérification, commandes de restauration, prochaine étape. Étiquetez une exécution autorisée non confinée comme telle, pas comme une réparation du sandbox.