На некоторых из наших рабочих станций разработчиков мы получали ужасное сообщение: «Этот список управления доступом не имеет канонической формы и поэтому не может быть изменен». ошибка, когда мы пытаемся установить разрешения для определенных папок. Нам не удалось выяснить, что портит эти ACL.
На данный момент я знаю единственный способ исправить это - щелкнуть правой кнопкой мыши поврежденную папку / файл, выбрать «Свойства» и щелкнуть вкладку «Безопасность». Затем Windows заметит повреждение и предложит исправить его. Мне это не нравится, потому что это делается вручную и требует, чтобы пользователь провел некоторые исследования, чтобы выяснить, какая папка / файл поврежден.
Есть ли где-нибудь сценарий или программа, которая сделает это автоматически? я вижу это icacls имеет /verify параметр, но он просто показывает мне, что ACL в файле / папке повреждены. Ничего не предлагает исправить.
Вы можете попробовать использовать простой сценарий PowerShell, чтобы заменить поврежденные файлы acl на acl другого файла: get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file
Я наконец смог придумать автоматическое решение для этого. Когда вы вызываете PowerShell Set-Acl командлет, он правильно изменит порядок списков ACL:
$path = C:\Path\To\Item\With\Borked\ACL
$acl = Get-Acl $path
Set-Acl $path $acl
Конечно, это может быть родительский каталог, в котором произошла ошибка, поэтому вам следует выполнить некоторые обходы, чтобы найти виновника. Использовать icacls C:\Path\To\Item\With\Suspect\CL /verify чтобы выяснить, нуждается ли что-то в ремонте.
В нашей среде вероятным виновником является Cygwin: когда он создает каталоги, он предпочитает предоставлять для них разрешения в стиле POSIX, вместо того чтобы полагаться на Windows для управления безопасностью файловой системы.
У меня возникла двойная проблема: неканонический ACL + ошибочное правило, объявленное для NULL SID (WTH?). Я предполагаю, что это было вызвано версией git для cygwin.
Во всяком случае, в моем случае повторное применение тем же ACL не имел никакого смысла:
> 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
Поэтому мне пришлось явно применить ACL из файла, имеющего правильный, как упоминалось @mschneider
icacls также может это исправить:
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
Другие удобные команды, эквивалент 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
Эта проблема возникает при использовании Cygwin. Он пытается имитировать права доступа к файлам POSIX поверх списков контроля доступа Windows. Это часто приводит к неканоническим ACL, которые являются законными, но не могут быть обработаны должным образом с помощью explorer.exe.
Вы можете отключить эту проблемную эмуляцию, установив с помощью опции "noacl", например в /etc/fstab:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0