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
И чем вызвано такое несоответствие мне неизвестно. Но в качестве теоретической справки это может быть полезным.