Corrigindo erros “Esta lista de controle de acesso não está em forma canônica” a partir da linha de comando

Question

Em várias de nossas estações de trabalho de desenvolvedores, temos recebido o temido "Esta lista de controle de acesso não está em formato canônico e, portanto, não pode ser modificada". erro quando tentamos definir permissões em determinadas pastas. Nós não conseguimos descobrir o que está corrompendo essas ACLs.

Neste momento, a única maneira que eu sei para consertá-lo é clicar com o botão direito do mouse na pasta / arquivo corrompido, escolher Propriedades e clicar na guia Segurança. O Windows observará a corrupção e oferecerá para corrigi-lo. Não gosto disso porque é manual e exige que o usuário faça algumas investigações para descobrir qual pasta / arquivo está corrompido.

Existe algum script ou programa em algum lugar que faça isso automaticamente? Eu vejo que icacls tem um parâmetro /verify , mas apenas me mostra que as ACLs em um arquivo / pasta estão corrompidas. Não oferece para consertar nada.

    

Answer 1

Eu finalmente consegui descobrir uma correção automatizada para isso. Quando você chamar o cmdlet Set-Acl do PowerShell, ele reordenará as ACLs corretamente:

$path = C:\Path\To\Item\With\Borked\ACL
$acl = Get-Acl $path
Set-Acl $path $acl

Claro, pode ser um pai do diretório que está bagunçado, então você deve fazer um pouco para encontrar o culpado. Use icacls C:\Path\To\Item\With\Suspect\CL /verify para descobrir se algo precisa de reparo.

Em nosso ambiente, o Cygwin é o provável culpado: quando cria diretórios, ele gosta de dar permissões no estilo POSIX, em vez de depender do Windows para gerenciar a segurança do sistema de arquivos.

    

Answer 2

Você pode tentar usar um script simples do PowerShell para substituir os arquivos de interrupção acl pelo acl de outro arquivo: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file

    

Answer 3

Para mim, houve um problema duplo: a regra incorreta não canônica ACL + foi declarada para NULL SID (WTH?). Eu sugiro que isso foi causado pela versão cygwin do git.

De qualquer forma, no meu caso, a reaplicação da mesma ACL não fazia qualquer sentido:

> Set-Acl $f.FullName (Get-Acl $f.FullName)
> (Get-Acl $f.FullName).AreAccessRulesCanonical
False
> (Get-Acl $f.FullName).GetAccessRules($True, $False, [System.Security.Principal.NTAccount]) | ? {$_.Identityeference.Value -eq "NULL SID" }
FileSystemRights  : WriteExtendedAttributes, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadPermissions
AccessControlType : Deny
IdentityReference : NULL SID
IsInherited       : False
InheritanceFlags  : None
PropagationFlags  : None

Então eu tive que aplicar explicitamente o ACL do arquivo com o correto, como mencionado por @mschneider

    

Answer 4

icacls pode consertar também:

c:\> accesschk -q FILE
Error: FILE has a non-canonical DACL:
   Explicit Deny after Explicit Allow

c:\> icacls FILE /t /q /c /reset
Successfully processed 1 files; Failed processing 0 files

c:\> accesschk -q FILE
.. OK

Outros comandos úteis, equivalentes ao chmod 0777 FILE, raiz ARQUIVO FILE

  icacls  FILE /t /q /c /grant    :r Everyone:F
  icacls  FILE /t /q /c /grant    :r Everyone:F /inheritance:r
  icacls  FILE /t /q /c /setowner Administrators

    

Answer 5

Esse problema aparece ao usar o Cygwin. Ele tenta emular as permissões do arquivo POSIX sobre as ACLs do Windows. Isso freqüentemente leva a ACLs não-canônicas, que são legais, mas não podem ser tratadas adequadamente pelo explorer.exe .

Você pode desativar essa emulação problemática montando com a opção "noacl", por exemplo, em /etc/fstab :

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0

    

Answer 6

1. No IIS, clique com o botão direito na pasta com o problema
2. Editar permissões ...
3. Selecione a guia Segurança
4. Clique no botão "Editar" e salve (isso parece reordenar o acl)
5. Confirme todos os pop-ups