Corrección de errores de "Esta lista de control de acceso no está en forma canónica" desde la línea de comandos

En varias de nuestras estaciones de trabajo para desarrolladores, hemos recibido el temido "Esta lista de control de acceso no está en forma canónica y, por lo tanto, no se puede modificar". error cuando intentamos establecer permisos en ciertas carpetas. No hemos podido averiguar qué está corrompiendo estas ACL.

En este momento, la única forma en que sé solucionarlo es haciendo clic derecho en la carpeta / archivo dañado, elija Propiedades y haga clic en la pestaña Seguridad. Windows notará la corrupción y ofrecerá solucionarlo. No me gusta esto porque es manual y requiere que el usuario haga algunas investigaciones para descubrir qué carpeta / archivo está dañado.

¿Hay algún script o programa en algún lugar que lo haga automáticamente? Veo que icaclstiene un /verifyparámetro, pero solo me muestra que las ACL en un archivo / carpeta están dañadas. No ofrece arreglar nada.

Podría intentar utilizar un script simple de PowerShell para anular los archivos corruptos acl con el acl de otro archivo: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file

Finalmente pude encontrar una solución automática para esto. Cuando llame al Set-Aclcmdlet de PowerShell , volverá a ordenar las ACL correctamente:

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

Por supuesto, podría ser un padre del directorio que está en mal estado, por lo que debe recorrer un poco para encontrar al culpable. Úselo icacls C:\Path\To\Item\With\Suspect\CL /verifypara averiguar si algo necesita reparación.

En nuestro entorno, Cygwin es el probable culpable: cuando crea directorios, le gusta otorgar permisos de estilo POSIX sobre ellos, en lugar de confiar en Windows para administrar la seguridad del sistema de archivos.

Para mí hubo un doble problema: la regla errónea no canónica de ACL + declarada para NULL SID (WTH?). Sugiero que fue causado por la versión cygwin de git.

De todos modos, en mi caso, volver a aplicar la misma ACL no tenía ningún 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

Así que tuve que aplicar explícitamente ACL desde el archivo que tiene uno correcto, como lo menciona @mschneider

icacls puede arreglarlo también:

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

Otros comandos útiles, equivalentes a chmod 0777 FILE, chown root 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

Este problema aparece cuando se usa Cygwin. Intenta emular los permisos de archivo POSIX sobre las ACL de Windows. Con frecuencia, esto lleva a ACL no canónicas, que son legales pero que explorer.exe no puede tratar adecuadamente .

Puede desactivar esta emulación problemática montando con la opción "noacl", por ejemplo, en /etc/fstab:

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

1. En IIS, haga clic con el botón derecho en la carpeta con el problema
2. Editar permisos ...
3. Seleccione la pestaña Seguridad
4. Haga clic en el botón 'Editar' y guarde (esto parece reordenar la ACL)
5. Confirme todas las ventanas emergentes