Disclaimer: данный пост несёт исключительно теоретическую ценность. Никакой практической пользы от него вы не получите.

Блуждая по просторам интернетов, наткнулся на один свой пост, который уже похоронен в истории веков.

Как известно, при доступе к общим ресурсам (сетевым папкам) мы различаем 2 типа прав:

• Share Permissions
• NTFS Rights

Оба типа прав влияют на результирующие (эффективные) права пользователя при доступе к сетевому ресурсу. В общем смысле эффективные права будут являть собой наиболее ограничивающее разрешение из обоих типов прав. Например, на ресурс установлено право Share Permissions = Read, а NTFS = Full Control, то исходя из наиболее ограничивающего разрешения эффективным будет Read. Если Share Permissions = FullControl, а NTFS = Modify, то эффективным правом для пользователя будет Modify. Вот такая несложная схема. Т.е. там, где прав меньше, те и будут ваши :-) Как известно, эта проблема редко кого касается, т.к. обычно на уровне Share Permissions выдают FullControl на ресурс и дальше уже права регулируют за счёт NTFS. Как бы всё правильно, но если раскопать вопрос глубже, то появляются интересные моменты.

http://technet.microsoft.com/en-us/library/cc784499(WS.10).aspx – по этой ссылке можно найти сопоставление Share Permissons с NTFS Rights. Такое сопоставление удобно тем, что рассчитывать оба типа прав можно с использованием одних и тех же классов .NET, без необходимости городить отдельные библиотеки и классы для управления списками доступа ACL. Грубо говоря, фактическое сопоставление выглядит вот так (по схеме Share Permission = NTFS Right):

• Read = ReadAndExecute
• Change = Modify + DeleteSubfoldersAndFiles
• FullControl = FullControl

Но это в общем смысле. Внутри Windows это выглядит чуть сложнее, т.к. там появляется хитрое право Synchronize. Т.е. таблица уже имеет такой вид:

• Read = ReadAndExecute + Synchronize
• Change = Modify + DeleteSubfoldersAndFiles + Synchronize
• FullControl = FullControl (в обоих случаях Synchronize уже включено).

Обратите внимание на наличие DeleteSubfoldersAndFiles в Change. Windows оба этих типа прав рассчитывает через класс .NET – FileSystemRights и фактически их содержит не в текстовом виде, а в числовом. Вот как выглядят числовые сопоставления текстовым правам:

[↓] [vPodans] ([system.enum]::getnames([System.Security.AccessControl.FileSystemRights])) | %{@{$_ = ([System.Securit
y.AccessControl.FileSystemRights]"$_").value__}}

Name                           Value
----                           -----
ListDirectory                  1
ReadData                       1
WriteData                      2
CreateFiles                    2
CreateDirectories              4
AppendData                     4
ReadExtendedAttributes         8
WriteExtendedAttributes        16
Traverse                       32
ExecuteFile                    32
DeleteSubdirectoriesAndFiles   64
ReadAttributes                 128
WriteAttributes                256
Write                          278
Delete                         65536
ReadPermissions                131072
Read                           131209
ReadAndExecute                 131241
Modify                         197055
ChangePermissions              262144
TakeOwnership                  524288
Synchronize                    1048576
FullControl                    2032127


[↓] [vPodans]

Как видно из таблички, FullControl является суммой всех перечисленных прав. Давайте разберём, что такое Modify, т.е. какие права нужно иметь для получения этого Modify:

• ListFolder - 1
• CreateFiles - 2
• Createfolders(Directories) - 4
• ReadExtendedAttributes - 8
• WriteExtendedAttributes - 16
• Traverse - 32
• ReadAttributes - 128
• WriteAttributes - 256
• Delete - 65536
• ReadPermissions – 131072

В этом легко убедиться, т.к. если мы сложим все эти цифры, то получим 197055 (как и отражено в таблице). Обратимся к ссылке: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!170.entry.

Теперь нам нужно преобразовать права доступа в класс FileSystemRights. Преобразование типа прав так же было ранее мною описано в первой части Управление ACL в PowerShell. Пара слов о том, чем отличаются права Read, Change и Full Control в контексте разрешений сетевого ресурса от контекста разрешений NTFS. Этим правам в NTFS сопоставляются Read + Execute, Modify и Full Control соответственно и плюс право Synchonize. Поэтому давайте запишем маску доступа в переменную $ace:

$ace.AccessMask = [System.Security.AccessControl.FileSystemRights]"Modify, Synchronize"

Чтобы получить Change, нам достаточно к этому числу (197055) прибавить Synchronize (1048576):

[↓] [vPodans] ([System.Security.AccessControl.FileSystemRights]"Modify, Synchronize").value__
1245631

Вот это в понимании SecurityDescriptor является эквивалентом нашего Change. Но я чуть ранее просил вас обратить внимание на наличие DeleteSubfoldersAndFiles в Change. Но тут его уже всунуть просто некуда, т.к. 1245695 (это число получится, если к Modify прибавить Synchronize и DeleteSubfoldersAndFiles) не будет распознано SecurityDescriptor’ом в методе SetShareInfo, как валидное число.

Иными словами, что у нас получается:

1) Change в понимании фактических прав является суммой: Modify + DeleteSubfoldersAndDiles + Synchronize

2) Change в понимании .NET является суммой: Modify + Synchronize

И чем вызвано такое несоответствие мне неизвестно. Но в качестве теоретической справки это может быть полезным.