Права доступа

← →
Чапаев © (2007-01-07 16:12) [0]

Как файлу (или каталогу) установить права доступа по умолчанию?

Пытался брать права родителя и давать их потомку -- получается гадость. Пытался через ConvertStringSecurityDescriptorToSecurityDescriptor() задавать права "D:AI" или "D:AIAR" -- все права сбрасываются, флаг наследования не устанавливается. Пытался через SetSecurityDescriptorDacl() устанавливать DACL по умолчанию -- ничего.

Единственное, что придумалось -- создать новый файл и его права скопировать исходному файлу, но что-то мне такой способ не по душе.

Поможите, люди добрые, а то уже извилины узелками завязываются.

← →
Eraser © (2007-01-07 16:39) [1]

> [0] Чапаев © (07.01.07 16:12)

возможно надо в SetNamedSecurityInfo в параметре pDacl указать nil (не путать с пустым dacl!), при этом в параметре SecurityInfo указав DACL_SECURITY_INFORMATION. Хотя не проверял.

← →
Чапаев © (2007-01-07 16:41) [2]

> не путать с пустым dacl!
Не путаю. :о)

То, о чём ты говоришь, разрешит всем полный доступ к файлу, судя по справке.

← →
Eraser © (2007-01-07 16:42) [3]

> [2] Чапаев © (07.01.07 16:41)

значит это я попутал с пустым дескриптором безопасности )

← →
Eraser © (2007-01-07 17:39) [4]

попробуй тогда добавить в ACL ACE, тип которого INHERITED_ACE или INHERIT_ONLY_ACE. жаль не могу сейчас проверить.. (

← →
Чапаев © (2007-01-07 17:47) [5]

> [4] Eraser © (07.01.07 17:39)
Попробую.

← →
С (2007-01-07 18:26) [6]

А что понимается под правами по умолчанию? Если назначаемые системой, так они автоматически будут назначены системой при создании объекта, без каких-либо дополнительных действий с нашей стороны, ели указать NIL в соответствующем параметре. Это же касается наследуемых ACE, то есть тех, у которых установлены соответствующие флаги.

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

Все это очень хорошо описано в книге Рихтера и Кларка "Программирование серверных приложений для W2000".

> [6] С (07.01.07 18:26)

сейчас глянул Рихтера, он по этому поводу пишет следующее
ULONG lErr = SetNamedSecurityInfo( TEXT("Machine\\Software\\Jason"sKey"), SE_REGISTRY_KEY, DACL_SECURITY_INFORMATION|PROTECTED_DACL_SECURITY_INFORMATION, NULL, NULL, NULL, NULL); if (lErr != ERROR_SUCCESS){ // Error case }
NOTE
--------------------------------------------------------------------------------
Remember that a NULL DACL indicates that everyone has all access to the object (even the ability to write the security of the object). In the rare cases where it is appropriate to set NULL security to an object, you must protect the object"s DACL (or lack of DACL) from inherited ACEs. Otherwise, the system is forced to create a DACL that will include the ACEs inherited from parent objects, which immediately undermines your goal of NULL security for the object. On the other hand, this side effect of inherited security can be a convenient way to set an object"s DACL to include no ACEs except those inherited from parent objects.

т.е. по его словам, если из его кода убрать |PROTECTED_DACL_SECURITY_INFORMATION, то объект якобы унаследует ACL своего предка. Однако на практике у меня это не подтвердилось.

← →
С (2007-01-07 18:59) [8]

>Eraser © (07.01.07 18:52) [7]

Унаследоваться должны те ACE, у которых стоит флаг наследования - если только я ничего не путаю. Нет настроения, честно говоря, проверять или поднимать документы или исходники. Совсем пропало настроение:(

Права доступа Найти похожие ветки