java - 使用 Java 的 AclFileAttributeView 获取通用文件夹权限(如 GENERIC_ALL)

Question

我使用 Java7 中的 AclFileAttributeView 来读取 Windows 目录的文件夹权限。问题是我无法获得完整的概述，因为 AclFileAttributeView 不返回通用权限，如 GENERIC_ALL、GENERIC_WRITE、GENERIC_READ 和 GENERIC_EXECUTE(访问掩码中的四个高位)。事实上，当涉及到通用权限时，它会为我提供有关同一成员的其​​他 AclEntries 的错误信息。让我举个例子:

当我使用像 AccessChk 这样的工具列出系统帐户的 c:\windows 的 AclEntries 时，我得到以下信息:

[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

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

现在我使用以下代码运行我的 java 程序:

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

这为系统帐户提供了以下结果:

• NT AUTHORITY\SYSTEM:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/DELETE_CHILD/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/WRITE_ACL/WRITE_OWNER/SYNCHRONIZE:ALLOW
• 北领地AUTHORITY\SYSTEM:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW

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

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

有人遇到过同样的问题吗？我会尝试一些其他的 JRE，也许这会有所作为。

Answer 1

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

的原因

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

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