diagnosticar-falhas-de-acl-do-sandbox-windows

Diagnosticar falhas de ACL do sandbox Windows

Escreva toda solicitação de aprovação em palavras simples, no idioma do usuário. O prompt é tudo que o usuário lê antes de ampliar o acesso, então deve ser autoexplicativo: qual pasta o script acessa, que ele adiciona a entrada de controle total do usuário logado onde falta um direito e remove entradas de pacotes estrangeiros, que o conteúdo dos arquivos e proprietários não são alterados, e que o comando de recuperação impresso desfaz cada alteração. Mantenha códigos de erro, WRITE_DAC/WRITE_OWNER, SIDs S-1-15-2-*, icacls, ACL, ACE, nomes de veredito e opções fora da solicitação: escreva permissões de arquivo do Windows, não ACL ou ACE. Solicite uma vez, para um comando.

Um comando diagnostica e repara

O script não tem modos. -Path, -AllowRoot e -Out leem o caminho e todos os ancestrais e reparam o que as observações comprovam, na mesma execução:

• diretórios nessa cadeia que não possuem WRITE_DAC ou WRITE_OWNER efetivos recebem uma ACE de permissão de controle total para o usuário logado, porque o DSH não pode provisionar sua concessão de workspace sem eles;
• ACEs de permissão explícitas de pacotes AppContainer (S-1-15-2-*, exceto os grupos conhecidos terminados em 1 ou 2) são removidas em suas origens, ancestral primeiro, o que também remove o acesso desses pacotes;
• um diretório que o sandbox não consegue provisionar — o estado que seu erro de provisionamento relata na raiz do workspace — ou a própria raiz autorizada também tem sua subárvore pesquisada por essas ACEs na mesma execução, para que uma entrada mais profunda não precise de uma segunda solicitação. Essa varredura limitada relata diretórios truncados (truncated) e ilegíveis; se truncado, passe o caminho mais profundo que ainda falha mais uma vez.

Cada alteração é salva em backup e depois verificada pela releitura. -AllowRoot limita tudo: um objeto é alterado apenas quando é esse diretório ou estritamente dentro dele, para que uma raiz de workspace possa se reparar. Nunca divida isso em uma chamada de diagnóstico e uma chamada de reparo, nunca pergunte duas vezes por um reparo, e nunca passe uma opção de modo que não existe.

& '<diretório-da-habilidade>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<caminho-com-falha>' -AllowRoot '<diretório-autorizado>' -Out '<diretório-de-recuperação>'
exit $LASTEXITCODE

Substitua por caminhos completos e entre aspas. Mantenha -Out persistente e de propriedade do usuário, de preferência ao lado do workspace com falha; nunca use o diretório de recursos da habilidade, que é excluído quando a habilidade é descarregada. Passe um caminho por invocação.

Execute-o

Repita a operação com falha uma vez confinado. O script escreve permissões, o que o token confinado não pode fazer — execute-o lá e relataria a própria restrição do sandbox como um direito ausente — então solicite aprovação para esse único comando e execute-o não confinado. Uma execução confinada do script nunca é útil. Não confinado não eleva o token do Windows.

Diagnostique negações inesperadas de escritas no workspace, listagem ou caminhos normalmente legíveis; explique as esperadas: escritas fora do workspace, qualquer escrita em read-only, spawn EPERM em processos filhos canalizados, erros ConstrainedLanguage. Se a aprovação for recusada ou indisponível, relate o caminho como não diagnosticado e pare.

Leia a saída

Cada registro chega ao stdout, ao arquivo acl-report-*.jsonl em -Out e à linha final RECAP, que carrega os vereditos, alterações, verificações, recusas e varreduras. A saída da ferramenta mantém apenas o final, então leia o resumo primeiro e leia registros específicos do relatório quando não for suficiente. Confie nos registros de verification, nunca em ações completed. Decida a partir de details.nextAction:

nextAction	Significado
verify_original_confined_operation	Reparos verificados; repita a operação original confinado.
stop	Nada reparado, ou uma recusa encerrou a execução. Relate e pare.
restore_pending_then_stop	Reversão não verificada. Execute os comandos de recuperação impressos em ordem e depois pare.

A presença de uma ACE de negação por si só não estabelece causalidade, e o script nunca remove uma; as concessões S-1-4-* do DSH e a negação DeleteSubdirectoriesAndFiles para Everyone são esperadas, não conflitos. Uma negação que bloqueie o reparo encerra a execução sem reparo (REPAIR_REFUSED, ou GRANT_FAILED) após restaurar o que tentou. Cada alteração deixa dois arquivos em -Out (acl-backup-<id>.json e seu .ps1), e a execução imprime o comando ROLLBACK correspondente.

Após um reparo, e quando ele para

Repita a operação original com falha confinado. Um reparo verificado não é desfeito porque a operação original falha por um motivo adicional: continue a partir das novas observações e, se um caminho mais profundo ainda for negado, execute o mesmo comando lá — novamente uma chamada, uma aprovação.

Pare após qualquer reparo com falha ou recusado, ou verificação com falha. O script já restaurou as alterações dessa invocação; não a repita nem inicie outro reparo, e nunca remova uma ACE de negação manualmente.

Uma execução parada ainda deve uma decisão ao usuário. Nomeie o objeto bloqueador e o direito ou ACE que falta, o que foi alterado e o que foi revertido, os comandos de recuperação em ordem e o caminho do relatório. Apenas o usuário pode levantar o confinamento, então peça a ele para alternar esta sessão para acesso total (full access) temporariamente e diga o que isso possibilita: continuar trabalhando com ele ou pedir que você continue investigando esse problema de permissão de arquivo, já que o relatório já registra o mecanismo e as evidências. Em seguida, peça a ele para enviar esta sessão como feedback, citando os registros do relatório que importam, para que o cenário não tratado chegue até nós — apenas o que chegar a esta conversa viaja com ela. Por exemplo:

这个工作区被 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.

Nunca

• edite ACLs manualmente, altere um proprietário, apague uma negação ou substitua permissões filhas recursivamente;
• execute o script elevado, via UAC ou runas;
• amplie -AllowRoot para alcançar um ancestral, ou repita uma chamada negada ou com falha.

Relate no idioma do usuário: caminhos analisados, alterações, verificação, comandos de recuperação, próximo passo. Rotule uma execução autorizada não confinada como tal, não como um reparo de sandbox.