Задача стоит такая — защита ключа реестра.
системе нужно предоставить полный доступ (точнее читать, писать, удалять),
остальным — закрыть полностью доступ.

Вопрос 1: достаточно ли будет для SID'а SECURITY_NT_AUTHORITY — SECURITY_LOCAL_SYSTEM_RID установить в ACE в поле grfAccessMode значение SET_ACCESS (или GRANT_ACCESS — тоже вопрос),
для SECURITY_WORLD_SID_AUTHORITY — SECURITY_WORLD_RID — DENY_ACESS

Вопрос 2: какая логика (и/или) при применении нескольких ACE (в том числе если один разрешающий а другой запрещающий)

Вопрос 3: в группу everyone (представленной как я понимаю SECURITY_WORLD_SID_AUTHORITY — SECURITY_WORLD_RID) входит группа system SECURITY_NT_AUTHORITY — SECURITY_LOCAL_SYSTEM_RID)? Как я понимаю нет, но хотелось бы подтверждения.

Здравствуйте, Desert_Sun, Вы писали:

D_S>Задача стоит такая — защита ключа реестра.
D_S>системе нужно предоставить полный доступ (точнее читать, писать, удалять),
D_S>остальным — закрыть полностью доступ.

D_S>Вопрос 1: достаточно ли будет для SID'а SECURITY_NT_AUTHORITY — SECURITY_LOCAL_SYSTEM_RID установить в ACE в поле grfAccessMode значение SET_ACCESS (или GRANT_ACCESS — тоже вопрос),
D_S>для SECURITY_WORLD_SID_AUTHORITY — SECURITY_WORLD_RID — DENY_ACESS

Видимо речь идет о использовании ф. SetEntriesInAcl?
GRANT_ACCESS — добавит права к существующим уже, SET_ACCESS — заменит. Т.е, допустим для группы стояло разрешение на чтение. Нужно добавить разрешение на запись — тогда GRANT_ACCESS. Если нужно заменить права чтение/запись на только чтение — нужно SET_ACCESS.
Я думаю, будет недостаточно двух вызовов SetEntriesInAcl для SECURITY_NT_AUTHORITY и SECURITY_WORLD_SID_AUTHORITY — они не изменят права пользоватей других групп ( допустим, power user ). См п.2

D_S>Вопрос 2: какая логика (и/или) при применении нескольких ACE (в том числе если один разрешающий а другой запрещающий)
ACE просматриваются последовательно. Допустим в списке для юзера 1 последовательно находится два ACE — первый разрешает запись, второй — запрещает. В этом случае просмотр ACE будет заканчиваться на первом элементе и запись будет всегда разрешена.

D_S>Вопрос 3: в группу everyone (представленной как я понимаю SECURITY_WORLD_SID_AUTHORITY — SECURITY_WORLD_RID) входит группа system SECURITY_NT_AUTHORITY — SECURITY_LOCAL_SYSTEM_RID)? Как я понимаю нет, но хотелось бы подтверждения.
В группу everyone входят все пользователи, в том числе и относящиеся к группе System. Иначе получился бы парадокс: к объекту разрешен доступ всем, но система не может получить к нему доступа.

Я думаю Вам нужно сделать следующее.
1)Создать новый ACL: InitializeAcl
2)Добавить туда разрешающий ACE для NT_AUTHORITY: AddAccessAllowedAce
3)Присвоить ACL нужной ветви реестра: RegSetKeySecurity

Здравствуйте, TarasCo, Вы писали:


D_S>>Вопрос 2: какая логика (и/или) при применении нескольких ACE (в том числе если один разрешающий а другой запрещающий)
TC>ACE просматриваются последовательно. Допустим в списке для юзера 1 последовательно находится два ACE — первый разрешает запись, второй — запрещает. В этом случае просмотр ACE будет заканчиваться на первом элементе и запись будет всегда разрешена.

Т.е. исходя из такой логики например если список из ACE будет построен наоборот:
сначала для SECURITY_WORLD_SID_AUTHORITY — запрет, а потом для
SECURITY_NT_AUTHORITY — разрешение, то не получит доступ вообще никто?

И еще: а почему это не отразится на группах типа power user — они что не относятся к группе everyone? (им тоже нужно запретить доступ)

Здравствуйте, Desert_Sun, Вы писали:

D_S>Здравствуйте, TarasCo, Вы писали:


D_S>>>Вопрос 2: какая логика (и/или) при применении нескольких ACE (в том числе если один разрешающий а другой запрещающий)
TC>>ACE просматриваются последовательно. Допустим в списке для юзера 1 последовательно находится два ACE — первый разрешает запись, второй — запрещает. В этом случае просмотр ACE будет заканчиваться на первом элементе и запись будет всегда разрешена.

D_S>Т.е. исходя из такой логики например если список из ACE будет построен наоборот:
D_S>сначала для SECURITY_WORLD_SID_AUTHORITY — запрет, а потом для
D_S>SECURITY_NT_AUTHORITY — разрешение, то не получит доступ вообще никто?

IMHO, да

D_S>И еще: а почему это не отразится на группах типа power user — они что не относятся к группе everyone? (им тоже нужно запретить доступ)

Может быть так:
ACL:
ACE1: админам разрешить все
ACE2: power user разрешить чтение
ACE3: всем разрешить чтение.
Ваш подход привратит это в:
ACL:
ACE1: админам разрешить все
ACE2: power user разрешить чтение
ACE3: всем запретить доступ
Соответсвенно, power user ы продолжают иметь доступ на чтение

Здравствуйте, TarasCo, Вы писали:

TC>Ваш подход привратит это в:
TC>ACL:
TC>ACE1: админам разрешить все
TC>ACE2: power user разрешить чтение
TC>ACE3: всем запретить доступ
TC>Соответсвенно, power user ы продолжают иметь доступ на чтение

а что SECURITY_LOCAL_SYSTEM_RID содержит и админов и power пользователей?

Мне нужно, еще раз, только системе дать доступ,
а ВСЕМ остальным запретить (в том числе и админам).

Здравствуйте, Desert_Sun, Вы писали:

D_S>Здравствуйте, TarasCo, Вы писали:

TC>>Ваш подход привратит это в:
TC>>ACL:
TC>>ACE1: админам разрешить все
TC>>ACE2: power user разрешить чтение
TC>>ACE3: всем запретить доступ
TC>>Соответсвенно, power user ы продолжают иметь доступ на чтение

D_S>а что SECURITY_LOCAL_SYSTEM_RID содержит и админов и power пользователей?

Конечно, нет. Но меняя права для system и для everyone Вы не затроните ACE для administrator например и он останется в списке ACL (если он там есть ) без изменений и будет продолжать разрешать доступ.

D_S>Мне нужно, еще раз, только системе дать доступ,
D_S>а ВСЕМ остальным запретить (в том числе и админам).

Еще раз пишу:
Нужно создать новый список доступа ACL и поместить туда один разрешающий ACE для системы. После этого, все кроме системных пользователей обламаются гарантированно.

Здравствуйте, TarasCo, Вы писали:

TC>Еще раз пишу:
TC>Нужно создать новый список доступа ACL и поместить туда один разрешающий ACE для системы. После этого, все кроме системных пользователей обламаются гарантированно.

Спасибо большое.
Извиняюсь, что забыла сказать, что в SetEntriesInAcl сразу подразумевалось создать новый ACL, а не наследовать существующий. Поэтому и возникло непонимание.

D_S>>>>Вопрос 2: какая логика (и/или) при применении нескольких ACE (в том числе если один разрешающий а другой запрещающий)
TC>>>ACE просматриваются последовательно. Допустим в списке для юзера 1 последовательно находится два ACE — первый разрешает запись, второй — запрещает. В этом случае просмотр ACE будет заканчиваться на первом элементе и запись будет всегда разрешена.

D_S>>Т.е. исходя из такой логики например если список из ACE будет построен наоборот:
D_S>>сначала для SECURITY_WORLD_SID_AUTHORITY — запрет, а потом для
D_S>>SECURITY_NT_AUTHORITY — разрешение, то не получит доступ вообще никто?

TC>IMHO, да

Дело в том, что, насколько я помню, построить список иначе можете только вы сами. Все высокоуровневые функции строят DACL таким образом, что сначала идут записи с запрещающими ACE, а затем только с разрешающими. При этом список действительно просматривается последовательно, до нахождения записи ACE с соотв. правами и SID. Однака благодаря такому упорядочиванию запрещающие записи имеют "перевес" над разрешающими.