Corrigindo erros "Esta lista de controle de acesso não está em formato canônico" na linha de comando

Em várias estações de trabalho de desenvolvedores, recebemos 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ão conseguimos descobrir o que está corrompendo essas ACLs.

No momento, a única maneira de corrigir isso é clicar com o botão direito do mouse na pasta / arquivo corrompido, escolher Propriedades e clicar na guia Segurança. O Windows notará a corrupção e oferecerá corrigi-la. Não gosto disso porque é manual e requer que o usuário faça algumas investigações para descobrir qual pasta / arquivo está corrompido.

Existe um script ou programa em algum lugar que fará isso automaticamente? Vejo que icaclstem um /verifyparâmetro, mas apenas me mostra que as ACLs em um arquivo / pasta estão corrompidas. Não oferece para consertar nada.

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

Finalmente, consegui descobrir uma correção automatizada para isso. Quando você chama o Set-Aclcmdlet do PowerShell , ele solicita novamente as ACLs corretamente:

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

Obviamente, ele pode ser o pai do diretório que está bagunçado; portanto, você deve percorrer algumas etapas para encontrar o culpado. Use icacls C:\Path\To\Item\With\Suspect\CL /verifypara descobrir se algo precisa de reparo.

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

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

De qualquer forma, no meu caso, reaplicar a mesma ACL não fazia nenhum 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 a ACL do arquivo com a correta, como mencionado por @mschneider

O icacls também pode corrigi-lo:

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 do chown 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

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

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

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

1. No IIS, clique com o botão direito do mouse 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 a ACL)
5. Confirme todos os pop-ups