Java AclFileAttributeView 怎样读取文件的 ACL 条目

Java 读取文件 ACL 的基本写法是：用 Files.getFileAttributeView(path, AclFileAttributeView.class, ...) 取得视图，先判断是否为 null，再调用 getAcl()。返回的列表应保留顺序，逐条展示 type、principal、permissions 和 flags；视图不存在、读取失败、成功读取零条记录，必须是不同结果。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/attribute/AclFileAttributeView.html

采用“可选视图、保序展示”的读取模式

文件属性访问适合放在一个小而明确的适配层中：它接受 Path，声明符号链接处理方式，返回读取结果或抛出读取异常。上层展示代码不必猜文件系统细节，更不应该在读取失败后用空列表掩盖原因。

这种模式适合文件属性面板、运维诊断工具或权限清单导出。目标是说明文件记录了哪些 ACL 条目，而非替操作系统决定某个用户最终能否访问。下面是一个完整的 Java 17+ 单文件示例，保存为 ReadFileAcl.java，入口参数为一个你有权查询的文件路径。代码未在本文中执行，字段文字是输出格式约定，不是实际文件的权限结果。

import java.io.IOException;
import java.nio.file.AccessDeniedException;
import java.nio.file.Files;
import java.nio.file.InvalidPathException;
import java.nio.file.LinkOption;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;
import java.nio.file.attribute.AclEntry;
import java.nio.file.attribute.AclFileAttributeView;
import java.util.Collection;
import java.util.List;
import java.util.stream.Collectors;

public final class ReadFileAcl {
    // 只排序一条记录内部的集合，不改变 ACL 条目顺序。
    private static String names(Collection extends Enum>> values) {
        return values.stream().map(Enum::name).sorted()
                .collect(Collectors.joining(",", "[", "]"));
    }

    private static void printAcl(Path path) throws IOException {
        // 明确读取路径所指对象本身，不跟随末端符号链接。
        AclFileAttributeView view = Files.getFileAttributeView(
                path, AclFileAttributeView.class,
                LinkOption.NOFOLLOW_LINKS);
        if (view == null) {
            System.out.println("status=unsupported");
            return;
        }

        // 视图非空不代表实际读取已成功；异常留给调用边界处理。
        List entries = view.getAcl();
        System.out.println("status=read entries=" + entries.size());
        for (int index = 0; index 

示例选择 NOFOLLOW_LINKS：若最后一个路径组件是符号链接，关注链接本身的属性。若业务明确需要目标文件属性，可省略这个选项，使用默认跟随行为。两种选择应在界面或导出说明中写清楚，不能拿一份链接本身的结果解释另一份目标文件。

四个字段一起读，才能解释一条 ACL

AclEntry 的主体是一个 UserPrincipal，用 getName 取得展示名称；这并不保证名称是跨主机稳定的身份编号。type 表示条目类型，permissions 是权限集合，flags 描述继承和传播规则。这些字段共同组成条目，不能只提取权限名就丢掉主体和类型。

代码只对每条记录内的集合名称排序，让同一组字段易于比较；没有按主体、类型或权限重新排序 ACL 列表。Java ACL 模型将 ACL 定义为有序条目列表，因此需要保留 index。不要为了排版把同一用户的 ALLOW 和 DENY 合并成一条“最终权限”。

这里的 flags 不是 Windows 属性窗口中所有视觉标记的完整副本。例如，不能仅凭存在 FILE_INHERIT 就断言“这条记录继承自父目录”；它描述可向文件子项传播的规则。不要为匹配某个系统界面而补造 API 没有返回的字段。

null、空列表和 IOException 不应混在一起

view == null 表示该属性视图类型不可用。它不是“当前用户没有权限”的同义词，也不能证明路径存在。视图对象非空仍需实际调用 getAcl 才能读取属性；读取可能遇到权限不足、对象不存在或其他 I/O 错误。

示例将 AccessDeniedException 和 NoSuchFileException 单独展示，再保留 IOException 分支。具体提供者不一定把每种错误细分成这些子类，因此一般分支不能删除。程序显示的状态用于演示诊断分类，没有通过提高权限、修改 ACL 或切换账号来尝试绕过访问限制。

若成功读取且列表为空，只能说本次视图返回零条条目。不能把它显示成“所有人可访问”，也不能在读取失败时伪造一个同样的零条结果。工具界面至少应分别呈现“不支持”“读取失败”“读取成功，条目数为零”。

反例：把 ACL 清单当作有效访问权限计算器

假设列表中存在某主体的 ALLOW 条目，含 READ_DATA。这是一条可读的规则记录，却不足以直接宣告某次真实访问一定成功。用户所属组、其他条目、提供者映射以及操作系统的访问控制语义都可能影响最终判定；Java 的 ACL 模型与底层文件系统之间的映射也存在实现差异。

AclFileAttributeView 面向支持 NFSv4 ACL 模型或能与之明确映射的文件系统。不要仅凭“在 Windows 上运行”就承诺所有磁盘和路径都支持这个视图，也不要仅凭“在 Linux 上运行”就把系统存在 ACL 等同于 Java 一定提供该视图。可用性应由实际 Path 对应的提供者决定。

同样，NOFOLLOW_LINKS 只表达这里的链接处理策略，不会把路径读取变成具备抗竞态保证的安全边界。读取期间对象和权限仍可能变化；一份清单记录的是读取结果，不是之后操作必然成功的承诺。本文只读取属性，不调用 setAcl，也不打开文件内容。

把展示边界写进工具约定

如果需求是展示规则，保留顺序与四字段就足够清楚；如果需求是判断具体用户能否执行一次操作，应使用该平台适合的访问判定机制并明确调用身份，而不是在这一段 Java 展示代码里拼出一个简化规则引擎。

属性视图没有内容输入流那样的关闭动作，因此示例不需要 try-with-resources。若后续功能另外打开文件内容或目录流，那些资源应按各自接口关闭。将 ACL 展示模块与文件读写模块分开，也能避免把一次诊断查询意外扩展成权限修改。

为什么 getAcl 后修改列表没有改变文件？

getAcl 返回的是可修改的有序列表，修改这个 Java 列表不会自动更新文件 ACL。写回属于另一项明确的操作；本例没有写回代码，也不把读取接口当作权限修改入口。

只显示 entry.toString() 可以吗？

临时排障可以利用字符串表示，但要做稳定的表格和结构化导出，应分别读取四个字段。这样能够保留主体、类型和集合之间的区别，不依赖字符串排版细节。

文件路径不合法与文件不存在一样吗？

不一样。Path.of 可能因路径字符串格式不合法抛出 InvalidPathException；对象不存在通常发生在实际读取阶段，具体错误还要看提供者的异常报告。

参考资料：Java ACL 属性视图、Files 文件属性访问、AclEntry 字段定义。