Параметры ICACLS: Почему / T требуется с (OI) (OC)?

3

Если я использую ICACLS.exe для установки разрешений для папки с помощью такой команды, как

icacls "C:\Some\Directory" /grant "somedomain\someUser:(OI)(CI)F" /t

зачем нужна опция / t? Разве это не тот случай, когда (OI) (CI) приведет к наследованию разрешений для всех объектов в C:\Some\Directoryдереве?

Чтобы быть более конкретным, предположим, что в моем примере выше у меня есть каталог C:\Some\Directory\Tree. Предположим, что этот каталог не имеет явных разрешений. Добавление явного разрешения "somedomain \ someUser: (OI) (CI) F" к этому каталогу ничего не даст, поскольку он уже унаследован. Icacls даже делает это? (Изменить: да, если вы будете ждать достаточно долго!) Поэтому, если я знаю, что у дерева каталогов нет явных разрешений, мне действительно не нужна опция / t (которая тратит огромное количество времени на дерево каталогов 8 ТБ с сотнями миллионы файлов ...)

Дэвид И. Макинтош
источник

Ответы:

2

Разве это не тот случай, когда (OI) (CI) приведет к наследованию разрешений?

Нет. Это объясняется описанием для /t:

Пройдите по всем подпапкам, чтобы найти файлы / каталоги. Это позволит применить изменения разрешений ко всем подпапкам, независимо от того, настроены ли они на наследование разрешений от родителя .

Источник icacls

ДэвидПостилл
источник
Это на самом деле не отвечает на мой вопрос. В нем говорится: если наследование не установлено, оно будет копировать разрешения для всех вложенных папок (что явно выполняет нечто существенное); и если наследование установлено, оно также скопирует разрешения, но не говорит, почему это необходимо! Если наследование означает, ну, значит, наследование, то я не понимаю, зачем это нужно. Сам факт того, что они заявляют, «установлены ли они для наследования разрешений», говорит о том, что здесь действительно есть вопрос, на который нужно ответить.
Дэвид И. Макинтош
@ DavidI.McIntosh Существуют разные виды наследования. (OI)(CI)/tустановит наследование, (OI)(CI)если оно вообще не установлено, не установлено (IO)или не является какой-либо другой комбинацией, кроме(OI)(CI)
DavidPostill
Дэвид - У вас еще нет 1 000 000 представителей на SU? Прежде чем вы это узнаете, вы будете выше, чем Гарри "The Mac Daddy" MC!
Сок Pimp IT
@DavidPostill: твой второй комментарий все еще не дает мне понять - должно быть что-то фундаментальное, чего я не понимаю? Я отредактировал свой вопрос, чтобы быть немного более конкретным. Может быть, вы можете иметь другой взгляд? Благодарю.
Дэвид И. Макинтош
0

Некоторые эксперименты с тривиальным деревом каталогов показывают, что:

1) (OI) (CI) действительно приводит к тому, что разрешения наследуются - как, конечно, унаследованные ACE в DACL, а не явные ACE - для всех подобъектов (учитывая, что наследование не было отключено для подобъекта) , как и следовало ожидать.

2) Параметр / t заставляет icacls обойти дерево и добавить точно такое же разрешение для каждого подкаталога, что и явное разрешение.

В результате, если взглянуть на разрешения безопасности для подкаталога, вы увидите две идентичные записи, одна из которых является унаследованным разрешением, а другая - явным параметром разрешения каталога (если только наследование не было отключено в подкаталоге или другом вмешательстве). каталог).

Хочет это или нет - другой вопрос, но, скорее всего, нет. Наличие разрешения, указанного дважды, не особенно полезно, если только не произойдут какие-либо изменения в будущем, от которых вам нужно защититься.

В массивной файловой системе это может занять слишком много времени.

Тот факт, что в документации указано «установлены ли они для наследования разрешений», возможно, предупреждает вас:

1) копирование в качестве явных разрешений для всех подкаталогов может не потребоваться, если разрешение содержит (OI)(CI)

но

2) если подкаталог установлен не наследовать разрешения, это на самом деле выполняет нечто существенное: в таком каталоге разрешение не будет унаследовано от родителя (то есть (OI)(CI)наследование подавлено), но оно все равно будет существовать благодаря добавлено как явное разрешение.

Дэвид И. Макинтош
источник