Correzione degli errori "Questo elenco di controllo di accesso non è in forma canonica" dalla riga di comando

Su alcune delle nostre workstation per sviluppatori, abbiamo avuto il temuto "Questo elenco di controllo degli accessi non è in forma canonica e quindi non può essere modificato." errore quando proviamo a impostare le autorizzazioni su determinate cartelle. Non siamo stati in grado di capire cosa sta corrompendo questi ACL.

In questo momento, l'unico modo che conosco per risolverlo è fare clic con il pulsante destro del mouse sulla cartella / sul file danneggiati, selezionare Proprietà e fare clic sulla scheda Sicurezza. Windows noterà quindi la corruzione e si offrirà di risolverlo. Non mi piace perché è manuale e richiede all'utente di fare alcune ricerche per capire quale cartella / file è corrotto.

C'è uno script o un programma da qualche parte che lo farà automaticamente? Vedo che icaclsha un /verifyparametro, ma mi mostra solo che gli ACL su un file / cartella sono danneggiati. Non offre di riparare nulla.

È possibile provare a utilizzare un semplice script PowerShell per sovrascrivere i file currupt acl con l'acl di un altro file: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file

Sono stato finalmente in grado di capire una soluzione automatica per questo. Quando si chiama il Set-Aclcmdlet di PowerShell , riordinerà correttamente gli ACL:

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

Certo, potrebbe essere un genitore della directory che è incasinata, quindi dovresti fare un po 'di movimento per trovare il colpevole. Usa icacls C:\Path\To\Item\With\Suspect\CL /verifyper capire se qualcosa deve essere riparato.

Nel nostro ambiente, Cygwin è il probabile colpevole: quando crea directory, gli piace concedere autorizzazioni in stile POSIX, invece di affidarsi a Windows per gestire la sicurezza del file system.

Per me c'era un doppio problema: ACL non canonico + regola errata dichiarata per NULL SID (WTH?). Suggerisco che sia stato causato dalla versione cygwin di git.

Ad ogni modo, nel mio caso la riapplicazione della stessa ACL non aveva alcun senso:

> 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

Quindi ho dovuto applicare esplicitamente ACL dal file avendone uno corretto, come menzionato da @mschneider

icacls può risolverlo anche:

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

Altri comandi utili, equivalenti 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

Questo problema si presenta quando si utilizza Cygwin. Cerca di emulare le autorizzazioni per i file POSIX su ACL di Windows. Ciò porta spesso a ACL non canonici, che sono legali ma che non possono essere gestiti correttamente da explorer.exe .

È possibile disattivare questa emulazione problematica montando con l'opzione "noacl", ad es. In /etc/fstab:

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

1. In IIS, fare clic con il pulsante destro del mouse sulla cartella con il problema
2. Modifica autorizzazioni ...
3. Seleziona la scheda Sicurezza
4. Fai clic sul pulsante "Modifica" e salva (sembra riordinare l'acl)
5. Conferma tutti i popup