查找目录权限(奇怪的权限条目)
Find directory rights (weird rights entries)
DirectorySecurity fs;
string FolderPath = "C:/Program Files";
fs = Directory.GetAccessControl(FolderPath, AccessControlSections.All);
foreach (FileSystemAccessRule fileSystemAccessRule in fs.GetAccessRules(true,true,typeof(System.Security.Principal.NTAccount)))
{
userNameDomain = fileSystemAccessRule.IdentityReference.Value;
userRights = fileSystemAccessRule.FileSystemRights.ToString();
string[] row = { userNameDomain, userRights };
var listViewItem = new ListViewItem(row);
lv_perm.Items.Add(listViewItem);
}
在“常规”文件和文件夹(例如:C:/Users/Julien/Desktop/New folder
)上执行此操作时,一切似乎都很好:
列表视图:
但是,当我在具有“特殊”权限(例如:C:/Program Files
)的文件夹上执行此操作时,我得到了与奇怪的权限相关联的重复 IdentityReference.Value
:
列表视图不好:
当我在 C:/Program Files
属性中打开“权限”选项卡时,我没有那么多带有奇怪数字的权限条目。
也许我做错了什么?
编辑:从那个页面 Here:
Using .NET you may think that determining which permissions are
assigned to a directory/file should be quite easy, as there is a
FileSystemRights Enum defined that seems to contain every possible
permission that a file/directory can have and calling
AccessRule.FileSystemRights returns a combination of these values.
However, you will soon come across some permissions where the value in
this property does not match any of the values in the FileSystemRights
Enum (I do wish they wouldn’t name some properties with the same name
as a Type but hey).
The end result of this is that for some files/directories you simply
cannot determine which permissions are assigned to them. If you do
AccessRule.FileSystemRights.ToString then for these values all you see
is a number rather than a description (e.g Modify, Delete, FullControl
etc). Common numbers you might see are:
-1610612736, –536805376, and 268435456
To work out what these permissions actually are, you need to look at
which bits are set when you treat that number as 32 separate bits
rather than as an Integer (as Integers are 32 bits long), and compare
them to this diagram:
msdn.microsoft.com/en-us/library/aa374896(v=vs.85).aspx
So for example, -1610612736 has the first bit and the third bit set,
which means it is GENERIC_READ combined with GENERIC_EXECUTE. So now
you can convert these generic permissions into the specific file
system permissions that they correspond to.
You can see which permissions each generic permission maps to here:
msdn.microsoft.com/en-us/library/aa364399.aspx. Just be aware
that STANDARD_RIGHTS_READ, STANDARD_RIGHTS_EXECUTE and
STANDARD_RIGHTS_WRITE are all the same thing (no idea why, seems
strange to me) and actually all equal the
FileSystemRights.ReadPermissions value.
所以我认为,因为 GetAccessRules
无法分组,例如:
NT SERVICE\TrustedInstaller FullControl
和
NT SERVICE\TrustedInstaller 268435456
他创建了 2 个不同的条目。
我必须更正 FileSystemRights 以便它们适合枚举。
268435456 - FullControl
-536805376 - Modify, Synchronize
-1610612736 - ReadAndExecute, Synchronize
这个问题从 2014 年就存在了。今天仍然存在。
你没有做坏事。 access mask 实际上在内部(和文件系统)表示为 int
,但枚举 FileSystemRights
不完整。
因此,可视化工具和那些将 FileSystemRights
值转换为字符串的函数将不知所措,只会给你数值(但作为 string
)。
这意味着为了理解它们,您必须检查 WinNT.h
(来自 Windows SDK)并查找所有可能的访问掩码值 - 包括通用值 - 以及提供一种将数字表示形式转换为更易于阅读的字符串的手动方法。
您遇到的似乎是两个不同的 ACE,它们具有不同的(但语义上等效的)访问掩码。这很好,并且在野外发生(正如您的屏幕截图所证明的!)。然而.NET框架选择忽略这个问题。
如果您使用 Powershell 的 Get-Acl
或 icacls
(自 Windows 2000 年以来一直使用的工具)查看 ACL,您会发现存在潜在差异各个 ACE 如何继承或传播到文件系统层次结构中。
另一种方法是调用 MapGenericMask()
并让它执行映射。所以当你给它 GENERIC_ALL
(== 0x10000000) 时,它会 return 0x001f01ff,对应于 FileSystemRights.FullControl
。这样您就可以将通用访问掩码“弯曲”为 .NET 框架可以理解的形式。
DirectorySecurity fs;
string FolderPath = "C:/Program Files";
fs = Directory.GetAccessControl(FolderPath, AccessControlSections.All);
foreach (FileSystemAccessRule fileSystemAccessRule in fs.GetAccessRules(true,true,typeof(System.Security.Principal.NTAccount)))
{
userNameDomain = fileSystemAccessRule.IdentityReference.Value;
userRights = fileSystemAccessRule.FileSystemRights.ToString();
string[] row = { userNameDomain, userRights };
var listViewItem = new ListViewItem(row);
lv_perm.Items.Add(listViewItem);
}
在“常规”文件和文件夹(例如:C:/Users/Julien/Desktop/New folder
)上执行此操作时,一切似乎都很好:
列表视图:
但是,当我在具有“特殊”权限(例如:C:/Program Files
)的文件夹上执行此操作时,我得到了与奇怪的权限相关联的重复 IdentityReference.Value
:
列表视图不好:
当我在 C:/Program Files
属性中打开“权限”选项卡时,我没有那么多带有奇怪数字的权限条目。
也许我做错了什么?
编辑:从那个页面 Here:
Using .NET you may think that determining which permissions are assigned to a directory/file should be quite easy, as there is a FileSystemRights Enum defined that seems to contain every possible permission that a file/directory can have and calling AccessRule.FileSystemRights returns a combination of these values. However, you will soon come across some permissions where the value in this property does not match any of the values in the FileSystemRights Enum (I do wish they wouldn’t name some properties with the same name as a Type but hey).
The end result of this is that for some files/directories you simply cannot determine which permissions are assigned to them. If you do AccessRule.FileSystemRights.ToString then for these values all you see is a number rather than a description (e.g Modify, Delete, FullControl etc). Common numbers you might see are:
-1610612736, –536805376, and 268435456
To work out what these permissions actually are, you need to look at which bits are set when you treat that number as 32 separate bits rather than as an Integer (as Integers are 32 bits long), and compare them to this diagram: msdn.microsoft.com/en-us/library/aa374896(v=vs.85).aspx
So for example, -1610612736 has the first bit and the third bit set, which means it is GENERIC_READ combined with GENERIC_EXECUTE. So now you can convert these generic permissions into the specific file system permissions that they correspond to.
You can see which permissions each generic permission maps to here: msdn.microsoft.com/en-us/library/aa364399.aspx. Just be aware that STANDARD_RIGHTS_READ, STANDARD_RIGHTS_EXECUTE and STANDARD_RIGHTS_WRITE are all the same thing (no idea why, seems strange to me) and actually all equal the FileSystemRights.ReadPermissions value.
所以我认为,因为 GetAccessRules
无法分组,例如:
NT SERVICE\TrustedInstaller FullControl
和
NT SERVICE\TrustedInstaller 268435456
他创建了 2 个不同的条目。
我必须更正 FileSystemRights 以便它们适合枚举。
268435456 - FullControl
-536805376 - Modify, Synchronize
-1610612736 - ReadAndExecute, Synchronize
这个问题从 2014 年就存在了。今天仍然存在。
你没有做坏事。 access mask 实际上在内部(和文件系统)表示为 int
,但枚举 FileSystemRights
不完整。
因此,可视化工具和那些将 FileSystemRights
值转换为字符串的函数将不知所措,只会给你数值(但作为 string
)。
这意味着为了理解它们,您必须检查 WinNT.h
(来自 Windows SDK)并查找所有可能的访问掩码值 - 包括通用值 - 以及提供一种将数字表示形式转换为更易于阅读的字符串的手动方法。
您遇到的似乎是两个不同的 ACE,它们具有不同的(但语义上等效的)访问掩码。这很好,并且在野外发生(正如您的屏幕截图所证明的!)。然而.NET框架选择忽略这个问题。
如果您使用 Powershell 的 Get-Acl
或 icacls
(自 Windows 2000 年以来一直使用的工具)查看 ACL,您会发现存在潜在差异各个 ACE 如何继承或传播到文件系统层次结构中。
另一种方法是调用 MapGenericMask()
并让它执行映射。所以当你给它 GENERIC_ALL
(== 0x10000000) 时,它会 return 0x001f01ff,对应于 FileSystemRights.FullControl
。这样您就可以将通用访问掩码“弯曲”为 .NET 框架可以理解的形式。