Windows 샌드박스 ACL 실패 진단
모든 승인 요청은 일반적인 언어로, 사용자의 언어로 작성하세요. 프롬프트는 사용자가 접근 권한을 확대하기 전에 읽는 유일한 내용이므로, 독립적으로 이해될 수 있어야 합니다: 스크립트가 접근하는 폴더, 권한이 누락된 곳에 로그인 사용자의 모든 권한 항목을 추가하고 외부 패키지 항목을 제거한다는 점, 파일 내용과 소유자는 변경되지 않는다는 점, 그리고 출력된 복구 명령이 각 변경 사항을 취소한다는 점을 포함하세요. 오류 코드, WRITE_DAC/WRITE_OWNER, S-1-15-2-* SID, icacls, ACL, ACE, 판정 이름 및 스위치는 요청에 포함하지 마세요. Windows 파일 권한이라고 쓰고 ACL이나 ACE라고 쓰지 마세요. 한 번에 하나의 명령에 대해 한 번만 요청하세요.
하나의 명령이 진단하고 복구합니다
이 스크립트에는 모드가 없습니다. -Path, -AllowRoot 및 -Out은 경로와 모든 상위 경로를 읽고 관찰 결과에 따라 필요한 복구를 같은 실행에서 수행합니다:
- 해당 체인의 디렉터리 중 유효한
WRITE_DAC또는WRITE_OWNER권한이 없는 디렉터리는 로그인 사용자에게 모든 권한 허용 ACE를 받습니다. DSH가 작업 공간 권한을 프로비저닝하려면 이 권한이 필요하기 때문입니다. - 명시적 AppContainer 패키지 허용 ACE (
S-1-15-2-*, 단 1 또는 2로 끝나는 잘 알려진 그룹 제외)는 해당 소스에서 제거되며, 상위 경로부터 먼저 제거되어 해당 패키지의 접근 권한도 함께 제거됩니다. - 샌드박스가 프로비저닝할 수 없는 디렉터리(작업 공간 루트에 대한 프로비저닝 오류가 보고하는 상태) 또는 승인된 루트 자체도 같은 실행에서 하위 트리에서 해당 ACE를 검색하므로, 더 깊은 항목에 대해 두 번째 요청이 필요하지 않습니다. 이 제한된 검색은
truncated및 읽을 수 없는 디렉터리를 보고합니다. truncated인 경우, 여전히 실패하는 더 깊은 경로를 다시 한 번 전달하세요.
모든 변경 사항은 백업된 후 다시 읽어서 확인됩니다. -AllowRoot는 모든 작업의 범위를 제한합니다: 객체는 해당 디렉터리이거나 그 내부에 있는 경우에만 변경되므로, 작업 공간 루트가 스스로 복구할 수 있습니다. 진단 호출과 복구 호출을 분리하지 말고, 하나의 복구에 대해 두 번 요청하지 말며, 존재하지 않는 모드 스위치를 전달하지 마세요.
& '<skill-directory>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<failing-path>' -AllowRoot '<authorized-directory>' -Out '<recovery-directory>'
exit $LASTEXITCODE
전체 경로를 따옴표로 묶어서 전달하세요. -Out은 지속적이고 사용자 소유의 경로로 유지하며, 가능하면 실패하는 작업 공간 옆에 두세요. 스킬 리소스 디렉터리는 사용하지 마세요. 스킬이 언로드되면 삭제됩니다. 호출당 하나의 경로만 전달하세요.
실행하기
실패하는 작업을 제한된 환경에서 한 번 반복하세요. 스크립트는 권한을 쓰는데, 제한된 토큰으로는 이 작업을 수행할 수 없습니다. 제한된 환경에서 실행하면 샌드박스 자체의 제한을 누락된 권한으로 잘못 보고할 것입니다. 따라서 해당 명령에 대한 승인을 요청하고 제한되지 않은 환경에서 실행하세요. 제한된 환경에서의 스크립트 실행은 유용하지 않습니다. 제한되지 않은 환경이 Windows 토큰을 상승시키지는 않습니다.
작업 공간 쓰기, 나열 또는 일반적으로 읽을 수 있는 경로의 예기치 않은 거부를 진단하고, 예상되는 거부는 설명하세요: 작업 공간 외부 쓰기, read-only에서의 쓰기, 파이프된 하위 프로세스 spawn EPERM, ConstrainedLanguage 오류 등. 승인이 거부되거나 불가능한 경우, 경로를 진단되지 않은 것으로 보고하고 중지하세요.
출력 읽기
모든 레코드는 stdout, -Out 아래의 acl-report-*.jsonl 파일 및 최종 RECAP 라인에 도달합니다. RECAP에는 판정, 변경 사항, 확인, 거부 및 검색 결과가 포함됩니다. 도구 출력은 꼬리 부분만 유지하므로, 먼저 RECAP을 읽고, 그것으로 충분하지 않을 때만 보고서에서 특정 레코드를 읽으세요. verification 레코드를 신뢰하고, completed 작업은 신뢰하지 마세요. details.nextAction에서 결정하세요:
nextAction | 의미 |
|---|---|
verify_original_confined_operation | 복구가 확인되었습니다. 원래 작업을 제한된 환경에서 반복하세요. |
stop | 복구된 항목이 없거나, 거부로 인해 실행이 종료되었습니다. 보고하고 중지하세요. |
restore_pending_then_stop | 확인되지 않은 롤백입니다. 출력된 복구 명령을 순서대로 실행한 후 중지하세요. |
거부 ACE의 존재 자체만으로 인과 관계를 확립할 수 없으며, 스크립트는 절대 이를 제거하지 않습니다. DSH의 S-1-4-* 권한 부여와 Everyone의 DeleteSubdirectoriesAndFiles 거부는 예상되는 것이며 충돌이 아닙니다. 복구를 차단하는 거부는 시도된 사항을 복원한 후 복구 없이 실행을 종료합니다(REPAIR_REFUSED 또는 GRANT_FAILED). 각 변경 사항은 -Out에 두 개의 파일(acl-backup-<id>.json 및 .ps1)을 남기며, 실행은 일치하는 ROLLBACK 명령을 출력합니다.
복구 후 및 중지 시
원래 실패한 작업을 제한된 환경에서 반복하세요. 확인된 복구는 원래 작업이 다른 이유로 실패한다고 해서 취소되지 않습니다. 새로운 관찰 결과를 바탕으로 계속 진행하고, 더 깊은 경로가 여전히 거부되면 동일한 하나의 명령을 다시 실행하세요. 다시 한 번의 호출, 한 번의 승인입니다.
실패하거나 거부된 복구 또는 실패한 확인 후에는 중지하세요. 스크립트는 이미 해당 호출의 변경 사항을 복원했습니다. 반복하거나 다른 복구를 시작하지 말고, 수동으로 거부 ACE를 제거하지 마세요.
중지된 실행은 여전히 사용자에게 결정을 제시해야 합니다. 차단하는 객체와 누락된 권한 또는 ACE, 변경된 사항과 롤백된 사항, 순서대로의 복구 명령, 보고서 경로를 명시하세요. 오직 사용자만이 제한을 해제할 수 있으므로, 이 세션을 일시적으로 완전 권한(full access, 중국어 UI: 完全权限)으로 전환하라고 요청하고, 그렇게 하면 무엇이 열리는지 설명하세요: 그 상태에서 계속 작업하거나, 파일 권한 문제를 계속 조사하도록 요청할 수 있습니다. 보고서에는 이미 메커니즘과 증거가 기록되어 있습니다. 그런 다음 이 세션을 피드백으로 보내도록 요청하고, 관련 보고서 레코드를 인용하여 처리되지 않은 시나리오가 우리에게 전달되도록 하세요. 이 대화에 있는 내용만 함께 전달됩니다. 예시:
이 작업 공간은 Windows 파일 권한에 의해 차단되었습니다:
<객체>에<누락된 권한 / 문제의 항목>. 이 세션을 '완전 권한'(full access, 完全权限)으로 임시 전환하여 계속 작업할 수 있습니다. 전환 후에는 작업을 바로 계속하거나, 이 파일 권한 문제를 계속 조사하도록 요청할 수 있습니다(보고서에는 이미 메커니즘과 증거가 있습니다). 또한 이 세션을 피드백으로 보내 주시면 이 시나리오를 처리할 수 있도록 하겠습니다.
절대 하지 말 것
- 수동으로 ACL을 편집하거나, 소유자를 변경하거나, 거부를 지우거나, 자식 권한을 재귀적으로 대체하지 마세요.
- UAC 또는
runas를 통해 스크립트를 상승된 권한으로 실행하지 마세요. -AllowRoot를 확장하여 상위 경로에 도달하지 말고, 거부되거나 실패한 호출을 반복하지 마세요.
사용자의 언어로 보고하세요: 분석된 경로, 변경 사항, 확인, 복구 명령, 다음 단계. 승인된 제한되지 않은 실행을 샌드박스 복구가 아닌 것으로 표시하세요.