查找目录权限(奇怪的权限条目)

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-Aclicacls(自 Windows 2000 年以来一直使用的工具)查看 ACL,您会发现存在潜在差异各个 ACE 如何继承或传播到文件系统层次结构中。

另一种方法是调用 MapGenericMask() 并让它执行映射。所以当你给它 GENERIC_ALL (== 0x10000000) 时,它会 return 0x001f01ff,对应于 FileSystemRights.FullControl。这样您就可以将通用访问掩码“弯曲”为 .NET 框架可以理解的形式。