windows使用Java的AclFileAttributeView获取通用文件夹权限（如generic_ALL）

Question

我使用Java7中的AclFileAttributeView读取Windows目录的文件夹权限。问题是，我无法获得完整的概述，因为AclFileAttributeView不返回泛型权限，如generic_ALL、generic_WRITE、generic_READ和generic_EXECUTE（访问掩码中的四个高阶位）。事实上，当涉及到通用权限时，它给了我关于同一成员的其他acentry的错误信息。让我举个例子：

当我使用AccessChk之类的工具为系统帐户列出c:\windows的acentries时，我得到以下信息：

[2] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
  FILE_ADD_FILE
  FILE_ADD_SUBDIRECTORY
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  FILE_WRITE_ATTRIBUTES
  FILE_WRITE_EA
  DELETE
  SYNCHRONIZE
  READ_CONTROL
[3] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
    [OBJECT_INHERIT_ACE]
    [CONTAINER_INHERIT_ACE]
    [INHERIT_ONLY_ACE]
  GENERIC_ALL

正如您所看到的，第一个acentry仅适用于文件夹本身，并且具有特殊权限WRITE_ACL和WRITE_OWNER。 第二个acentry仅适用于子文件夹和文件，并包含通用权限generic_ALL。这正是我在Windows资源管理器的“安全”选项卡中看到的。系统帐户有两条记录，一条仅适用于文件夹（具有权限子集），另一条适用于具有完全控制权的子文件夹/文件

现在，我使用以下代码运行java程序：

AclFileAttributeView view = Files.getFileAttributeView(path, AclFileAttributeView.class);
System.out.println(view.getAcl());

这将为系统帐户提供以下结果：

• NT权限\系统：读取\数据/写入\数据/附加\数据/读取\命名\属性/写入\命名\属性/执行/删除\子/读取\属性/写入\属性/删除/读取\ ACL/写入\ ACL/写入\所有者/同步：允许
• 新界 权限\系统：文件\继承/目录\继承/仅继承：允许

第一个acentry仅适用于文件夹本身，并包含所有特殊权限，包括WRITE_ACL和WRITE_OWNER，这是不正确的！第二个acentry没有显示任何权限，因为它有通用的所有权限

我不确定这是哪里出了问题，似乎JRE只是解码操作系统（sun.nio.fs.WindowsSecurityDescriptor.decode）给出的ACE位掩码

有没有人经历过同样的问题？我会尝试其他的JRE，也许这会有所不同

Answer 1

我最终使用反射来获取ACE的访问掩码（使用 太阳尼奥。财政司司长。WindowsNativeDispatcher。格塔斯）。使用访问掩码，我检查四个高位以确定通用权限

它还允许我获取继承的位，这在JRE规范中是不可用的。我获取“原始”ACL信息，这比Windows安全选项卡多得多。例如，我的c:\drive为内置的\Administrators提供了两个ACE，一个具有通用的\u ALL权限并传播到子文件夹和文件（而不是容器本身），另一个具有应用的特殊权限，根本没有任何标志（仅应用于当前容器）。Windows就是这样使用这些通用权限的。这同样适用于子文件夹，如Program Files目录，通用权限会被传播，每个子容器都有一个单独的ACE，用于只应用于容器本身的实际特殊权限

关于工具AccessChck，您确定要使用-l参数吗？这提供了更多信息和“原始”ACL信息

我已经使用JNA项目从服务器检索本地组。感谢您提供有关AdvApi32Util的提示！我会调查的。你在JRE中使用setACL方法的经验如何

我使用所有这些来发布一个工具，它将LDAP中的组成员身份与目录和文件中的ACL信息结合起来。所有这些信息都保存在本地数据库（或外部数据库）中，可用于创建概述。此概述提供了许多筛选选项，并显示特定用户或用户组（包括嵌套组成员）的权限信息。因为所有内容都保存在数据库中，所以它可以在几秒钟内为您提供概览，而不是每次都扫描整个网络。您还可以跟踪权限，它显示权限来自何处、来自哪个组成员或来自哪个文件夹等。它将包含修改单个ACE的功能，但重点是查看权限

该工具已准备好进行测试；）如果你有兴趣请告诉我。。。这个工具不是免费的，因为我花了很多时间来写，但是如果你感兴趣，请告诉我。我可以帮你拿到驾照。请参阅以下链接，以快速获得印象。别介意这个网站，它仍然提到这个工具的旧版本

Scan screenshot
Overview screenshot

Permission Analyzer 64bit
Permission Analyzer 32bit
Permission Analyzer 64bit with embedded JRE
Permission Analyzer 32bit with embedded JRE

Answer 2

我也遇到了同样的问题。事实证明the spec for AclFileAttributeView states它被设计成与RFC 3530: Network File System (NFS) version 4 Protocol兼容。在RFC 3530中，不支持通用_*值。我还查看了运行JVM的JDK代码源（从OpenJDK project下载自here）。在我看来，通过将适当的RFC3530标志映射到GENERIC_*和从GENERIC_*映射，可能会有一种方法使JVM兼容，但维护人员显然没有。这就是您的空条目NT AUTHORITY\SYSTEM:FILE\u INHERIT/DIRECTORY\u INHERIT/INHERIT\u ONLY:ALLOW

更糟糕的是，JVM不支持来自Windows安全描述符的SE_DACL_PROTECTED和SE_SACL_PROTECTED标志（这些标志是通过元标志（UN）PROTECTED_（S/D）ACL_Security_信息设置的，如注释here所示。如果使用工具AccessChk，它实际上会向您显示有效的ACE列表，而不是实际的ACE列表，AclFileAttributeView和其他Windows工具会这样做（查看FileTest）这就是ACE数量不同的原因。就我而言，我有9个A，但AccessChk有5个。在9个SID（用户或组）值中，有4个是真正重复的，其中给定SID的第一个ACE有权限，给定SID的第二个ACE没有权限，但只有SE_DACL_保护集或未设置

我不完全确定您想用这些ACL做什么，但我可能会根据您的意图为您提供解决方案。我继续对JNA project进行了修改，开始允许用户以更直接的方式修改Windows安全描述符。你可以看到我的合并请求here。我不知道他们多久向Maven public repo发布一次版本，所以您可能需要直接下载并编译源代码才能获得这些更改。有关如何获取对象的SD，请参阅GetNamedSecurity信息。然后，可以使用AdvApi32Util中的帮助API来管理安全描述符对象。请参阅public static SECURITY_DESCRIPTOR_RELATIVE getFileSecurityDescriptor(File file, boolean getSACL)，了解将SD转换为自相关格式的方法，然后该对象允许您在ACL中遍历ACE