引言：一个时代的落幕——理解被废弃的安全基石

在 Java 安全体系的宏伟殿堂中，java.io.FilePermission 曾是一根关键的承重柱。它作为 java.security.Permission 抽象类的具体实现，为 Java 的沙箱安全模型（Security Manager）提供了对文件系统访问进行细粒度控制的能力。其设计精巧，能够通过路径名和动作集合，精确地定义“谁可以在哪里做什么”。

然而，随着时代的发展，Java 平台的安全重心发生了根本性的转移。在 JDK 17 中，Security Manager 被标记为废弃；到了 JDK 25，FilePermission 本身也被正式宣告废弃（@Deprecated(since="25", forRemoval=true)），并明确指出：“This permission cannot be used for controlling access to resources as the Security Manager is no longer supported.”

这标志着一个时代的终结。但理解 FilePermission 的内部工作原理，其价值远不止于怀旧。它是一部活生生的软件工程教科书，展示了：

• 复杂权限模型的设计：如何用简单的数据结构（路径、掩码）表达复杂的授权逻辑。
• 向后兼容的艺术：如何在引入新特性（如 NIO 的 Path）的同时，保持与旧代码的兼容。
• 性能与安全的权衡：路径规范化（canonicalization）带来的安全性和性能开销。
• API 演进的哲学：一个核心 API 如何从辉煌走向废弃。

本文将深入 JDK 25 版本的 FilePermission 源码，对其进行一场全面而深刻的解剖。我们将探索其核心字段、通配符语义、双模式实现（旧版基于 String vs 新版基于 Path）、implies 方法的精妙逻辑、FilePermissionCollection 的高效合并策略，并最终理解其在现代 Java 生态中的历史定位。通过本文，您将不仅掌握一个类，更能洞悉 Java 平台安全模型的兴衰史。

---

第一章：FilePermission的本质与历史使命——沙箱安全的守护者

要真正理解 FilePermission，我们必须将其置于 Java 安全模型的历史背景中考量。

1.1 官方定义与继承体系

根据 Oracle Javadoc（JDK 25 版本），FilePermission 的定义如下：

“This class represents access to a file or directory. A FilePermission consists of a pathname and a set of actions valid for that pathname.”

这句话揭示了其两个核心要素：

• 路径名（Pathname）：可以是具体文件、目录，也可以是带有通配符（* 或 -）的模式，甚至是特殊的 <<ALL FILES>>。
• 动作集合（Actions）：由 "read", "write", "execute", "delete", "readlink" 组成的逗号分隔字符串。

在 Java 的类继承体系中，FilePermission 的位置如下：

java.lang.Object
  └── java.security.Permission
        └── java.security.BasicPermission
              └── java.io.FilePermission

作为 BasicPermission 的子类，它天然支持名称（即路径名）的层次结构，并通过 implies 方法实现了权限的包含关系。

1.2 设计初衷：构建安全沙箱

FilePermission 是 Java Security Manager 机制的核心组成部分。在 Applet 和早期 Web Start 应用盛行的时代，Security Manager 负责在运行时检查敏感操作（如文件 I/O、网络连接）是否被允许。

• 授权：通过 java.policy 文件，管理员可以授予代码特定的 FilePermission。例如：

  grant codeBase "file:/home/user/app/" {
      permission java.io.FilePermission "/tmp/*", "read,write";
      permission java.io.FilePermission "<<ALL FILES>>", "read";
  };
  

• 检查：当代码执行 new FileInputStream("/etc/passwd") 时，Security Manager 会创建一个 FilePermission("/etc/passwd", "read") 对象，并检查当前 AccessControlContext 中的权限集合是否 implies（蕴含）此权限。如果蕴含，则允许操作；否则，抛出 SecurityException。

这种模型为不受信任的代码提供了一个强大的隔离层。

1.3 @since 1.2 与 @Deprecated(since=“25”) 的对比

• @since 1.2：表明 FilePermission 自 Java 1.2 引入 Security Manager 增强功能以来，一直是平台安全的核心。
• @Deprecated(since="25", forRemoval=true)：标志着其历史使命的终结。现代 Java 应用更倾向于使用操作系统级别的容器化（如 Docker）或语言级别的模块系统（JPMS）来实现隔离，而非在 JVM 内部维护一个复杂的、性能开销大的运行时权限检查器。

---

第二章：源码逐行解读与核心字段分析——通配符背后的秘密

FilePermission 的源码是 JDK 中处理复杂字符串模式匹配和权限逻辑的典范。让我们深入 JDK 25 版本的实现。

2.1 OpenJDK 25 源码深度剖析

以下是 FilePermission 在 OpenJDK 25 中的关键部分源码：

// ... [版权信息]

package java.io;

import java.nio.file.*;
// ... other imports

@Deprecated(since="25", forRemoval=true)
public final class FilePermission extends Permission implements Serializable {
    // 动作掩码常量
    private static final int EXECUTE = 0x1;
    private static final int WRITE   = 0x2;
    private static final int READ    = 0x4;
    private static final int DELETE  = 0x8;
    private static final int READLINK= 0x10;
    private static final int ALL     = READ|WRITE|EXECUTE|DELETE|READLINK;

    // 核心字段
    private transient int mask;          // 动作的位掩码
    private transient boolean directory; // 路径是否代表目录
    private transient boolean recursive; // 是否是递归目录（"/-"）
    private String actions;              // 缓存的动作字符串

    // 旧模式 (nb == false) 字段
    private transient String cpath;      // 规范化的路径字符串

    // 新模式 (nb == true) 字段
    private transient Path npath;        // 规范化的 Path 对象
    private transient Path npath2;       // 备用 Path 对象（用于相对/绝对路径互操作）
    private transient boolean allFiles;  // 是否是 "<<ALL FILES>>"
    private transient boolean invalid;   // 路径是否无效

    // 双模式开关
    private static final boolean nb = initNb();
    // ...
}

关键字段分析：

2.1.1 动作掩码（Action Mask）：位运算的优雅

private static final int EXECUTE = 0x1; // 00001
private static final int WRITE   = 0x2; // 00010
private static final int READ    = 0x4; // 00100
// ...
private transient int mask;

• 设计思想：使用单个 int 的不同位来表示不同的权限动作。这是一种经典的位掩码（Bitmask）技术。
• 优势：
  • 空间效率：一个整数即可表示所有可能的动作组合。
  • 操作效率：权限的合并（OR）、检查（AND）等操作可以通过极快的位运算完成。
  • implies 逻辑简化：检查权限 A 是否蕴含 B，只需 (A.mask & B.mask) == B.mask。

2.1.2 双模式实现（Old vs New Behavior）：兼容性的智慧

这是 FilePermission 源码中最精妙的设计之一，通过 nb（new behavior）标志切换两种实现。

private static final boolean nb = initNb();

private static boolean initNb() {
    String flag = SecurityProperties.getOverridableProperty(
            "jdk.io.permissionsUseCanonicalPath");
    return switch (flag) {
        case "true" -> false;   // 旧模式：使用 canonical path
        case "false" -> true;   // 新模式：使用 normalized Path
        case null -> true;      // 默认：新模式
        default -> throw new RuntimeException(...);
    };
}

• 旧模式（nb = false） cpath:

  • 调用 File.getCanonicalPath() 进行路径规范化。
  • 优点：能解析符号链接、处理 DOS 8.3 短文件名、统一大小写（在 Windows 上），安全性更高。
  • 缺点：需要访问文件系统，性能开销大，且在某些情况下（如目标文件不存在）会失败。

• 新模式（nb = true） npath:

  • 使用 java.nio.file.Path 并调用 normalize()。
  • 优点：纯内存操作，不访问文件系统，性能极高。
  • 缺点：无法解析符号链接，对于 ../ 等相对路径的处理依赖于当前工作目录（通过 altPath 机制部分解决）。

• npath2 字段：这是一个天才的 hack。为了兼容旧代码（旧代码可能用相对路径授权，但新代码用绝对路径请求），FilePermission 会同时计算并存储路径的绝对形式和相对形式（相对于 user.dir）。在 implies 检查时，会尝试用两者分别匹配，极大地提高了新旧代码的互操作性。

2.1.3 通配符语义：* 与 - 的区别

FilePermission 支持两种强大的通配符：

• /path/*：匹配 /path/ 目录下的直接子文件和子目录（非递归）。
• /path/-：匹配 /path/ 目录下的所有文件和子目录，包括嵌套多层的（递归）。

源码通过 directory 和 recursive 两个布尔字段来区分这三种情况（普通文件、*、-）。

2.1.4 特殊令牌：<<ALL FILES>>

if (name.equals("<<ALL FILES>>")) {
    allFiles = true;
    // ...
}

• 这是一个全局通配符，拥有它的 FilePermission 对象可以 implies 任何其他 FilePermission 对象（只要动作掩码满足）。它是权限模型中的“超级用户”。

---

第三章：构造函数与初始化逻辑——从字符串到权限对象的旅程

FilePermission 的构造过程是其复杂性的集中体现。

3.1 核心构造函数 FilePermission(String path, String actions)

public FilePermission(String path, String actions) {
    super(path);
    init(getMask(actions));
}

流程分解：

1. getMask(actions): 将动作字符串（如 "read,write"）解析为位掩码（0x6）。这个方法非常健壮，能处理大小写、空格、逗号分隔等各种情况，并利用字符串常量池进行快速匹配优化。

2. init(int mask): 这是整个初始化的核心，根据 nb 标志选择不同的路径处理逻辑。

3.2 新模式（nb = true）下的 init 逻辑

// 1. 处理 <<ALL FILES>>
if (name.equals("<<ALL FILES>>")) { ... }

// 2. 将 "*" 临时转换为 "-" 以便统一处理
boolean rememberStar = false;
if (name.endsWith("*")) {
    rememberStar = true;
    name = name.substring(0, name.length()-1) + "-";
}

// 3. 创建并规范化 Path
npath = builtInFS.getPath(new File(name).getPath()).normalize();

// 4. 检查路径末尾是否是 "-"
Path lastName = npath.getFileName();
if (lastName != null && lastName.equals(DASH_PATH)) {
    directory = true;
    recursive = !rememberStar; // 关键！恢复 "*" 的非递归属性
    npath = npath.getParent(); // 移除末尾的 "-"
}

这个过程清晰地展示了如何将用户友好的通配符语法（* 和 -）转换为内部统一的、易于比较的数据结构。

3.3 旧模式（nb = false）下的 init 逻辑

旧模式主要依赖 File.getCanonicalPath() 来获取一个绝对的、规范化的路径字符串 cpath，然后通过字符串操作（如 startsWith）来判断路径包含关系。

---

第四章：核心方法 implies 深度剖析——权限蕴含的精妙算法

implies 方法是 FilePermission 的灵魂，它决定了一个权限是否比另一个更“宽泛”。

4.1 总体逻辑

@Override
public boolean implies(Permission p) {
    if (!(p instanceof FilePermission that))
        return false;
    // 1. 动作掩码检查: this 必须包含 that 的所有动作
    return ((this.mask & that.mask) == that.mask) 
           // 2. 路径蕴含检查
           && impliesIgnoreMask(that);
}

4.2 impliesIgnoreMask：路径蕴含的两种实现

4.2.1 新模式（基于 Path）的逻辑

boolean impliesIgnoreMask(FilePermission that) {
    // 1. 特殊情况处理
    if (allFiles) return true; // <<ALL FILES>> 蕴含一切
    if (that.allFiles) return false; // 除了自己，没人能蕴含 <<ALL FILES>>
    if (invalid || that.invalid) return false; // 无效权限不参与蕴含

    // 2. 通配符级别检查: this 的通配级别不能低于 that
    if ((this.recursive && that.recursive) != that.recursive
        || (this.directory && that.directory) != that.directory) {
        return false;
    }

    // 3. 核心：路径包含检查
    int diff = containsPath(this.npath, that.npath);
    // 递归权限：只要 that 在 this 的子树里就行
    if (diff >= 1 && recursive) return true;
    // 非递归目录权限：that 必须是 this 的直接子元素
    if (diff == 1 && directory && !that.directory) return true;

    // 4. 尝试备用路径 npath2
    if (this.npath2 != null) {
        // 对 npath2 执行相同的检查...
    }
    return false;
}

4.2.2 containsPath：路径深度计算

这是新模式下最核心的算法，用于计算一个路径 p2 相对于另一个路径 p1 的“深度”。

private static int containsPath(Path p1, Path p2) {
    // 1. 根路径必须相同
    if (!Objects.equals(p1.getRoot(), p2.getRoot())) return -1;

    // 2. 处理空路径（"."）
    // ...

    // 3. 移除公共前缀
    int i = 0;
    while (i < min(c1, c2) && p1.getName(i).equals(p2.getName(i))) i++;

    // 4. 检查剩余部分是否合法（不能有 ".."）
    // ...

    // 5. 返回深度: (p1剩余部分长度) + (p2剩余部分长度)
    return c1 - i + c2 - i;
}

举例：

• p1 = "/tmp", p2 = "/tmp/foo.txt" -> 公共前缀 /tmp，p1 剩余 0，p2 剩余 1 (foo.txt)，深度 = 0 + 1 = 1。
• p1 = "/tmp", p2 = "/tmp/sub/bar.txt" -> 深度 = 0 + 2 = 2。
• p1 = "/tmp", p2 = "/var/log" -> 根不同，返回 -1。

这个深度值直接决定了 implies 的结果。

4.2.3 旧模式（基于 String）的逻辑

旧模式主要依靠字符串的 startsWith 和 regionMatches 方法进行前缀匹配，逻辑相对简单但不够健壮（容易受路径分隔符、大小写等影响）。

---

第五章：FilePermissionCollection——高效权限集合的实现

单个 FilePermission 的 implies 逻辑已经很复杂，而 FilePermissionCollection 则在此基础上实现了高效的批量权限管理和合并。

5.1 数据结构：ConcurrentHashMap

private transient ConcurrentHashMap<String, Permission> perms;

• 使用 ConcurrentHashMap 保证了线程安全，允许多个线程并发地读取权限集合。

5.2 add 方法：智能合并

public void add(Permission permission) {
    perms.merge(fp.getName(), fp, (existingVal, newVal) -> {
        int oldMask = existingVal.getMask();
        int newMask = newVal.getMask();
        if (oldMask != newMask) {
            int effective = oldMask | newMask; // 合并动作掩码
            if (effective == newMask) {
                return newVal; // 新权限完全覆盖旧权限
            }
            if (effective != oldMask) {
                // 需要创建一个新权限，包含合并后的动作
                return newVal.withNewActions(effective);
            }
        }
        return existingVal;
    });
}

• 智能合并：如果向集合中添加一个与现有权限同名但动作不同的 FilePermission，集合不会简单地覆盖或忽略，而是会合并它们的动作掩码，创建一个新的、权限更宽泛的 FilePermission。这确保了权限集合的“单调性”（只增不减）。

5.3 implies 方法：高效查询

public boolean implies(Permission permission) {
    int desired = fperm.getMask();
    int effective = 0;
    int needed = desired;

    for (Permission perm : perms.values()) {
        // 只检查那些动作与 needed 有交集，并且路径能蕴含的权限
        if (((needed & fp.getMask()) != 0) && fp.impliesIgnoreMask(fperm)) {
            effective |= fp.getMask();
            if ((effective & desired) == desired) {
                return true; // 已经收集到所有需要的权限
            }
            needed = (desired & ~effective); // 更新还需要的权限
        }
    }
    return false;
}

• 早期终止：一旦收集到足够的权限（effective 包含了 desired 的所有位），就立即返回 true，无需遍历整个集合。
• 动态剪枝：通过 needed 变量，可以跳过那些不包含所需动作的权限，进一步提升性能。

---

第六章：序列化与向后兼容——跨越版本的桥梁

FilePermission 和 FilePermissionCollection 都实现了自定义的序列化逻辑，以确保在不同 JDK 版本间能正确读写。

6.1 FilePermission 的序列化

• writeObject: 仅序列化 actions 字符串，因为 mask 可以从 actions 重建。
• readObject: 反序列化 actions 后，调用 init(getMask(actions)) 重新初始化所有瞬态字段。这种方式保证了无论新旧模式，都能从序列化流中正确恢复。

6.2 FilePermissionCollection 的序列化

这是一个更复杂的例子，展示了如何在内部数据结构变更后保持序列化兼容性。

// 旧版本的字段
private Vector<Permission> permissions;

// 新版本的字段
private transient ConcurrentHashMap<String, Permission> perms;

// writeObject: 将 ConcurrentHashMap 转换为 Vector 再写入
// readObject: 从 Vector 读取并填充到 ConcurrentHashMap

• serialPersistentFields: 明确声明了要序列化的字段是旧的 Vector，而不是新的 ConcurrentHashMap。
• 无缝迁移：这种设计使得用新 JDK 序列化的 FilePermissionCollection 可以被旧 JDK 正确反序列化，反之亦然。

---

第七章：在 JDK 25 中的现代定位——理解废弃的原因

尽管 FilePermission 被废弃，但理解其废弃的原因对于把握 Java 平台的未来方向至关重要。

7.1 Security Manager 的局限性

• 性能开销：每次敏感操作都需要进行权限栈检查，对性能有显著影响。
• 复杂性：配置和调试 Security Manager 策略非常复杂，容易出错。
• 粒度问题：它是在代码级别（CodeSource）进行授权，而不是在应用或用户级别，这与现代微服务、容器化的部署模型不符。

7.2 现代替代方案

• 操作系统级隔离：使用 Linux namespaces, cgroups, SELinux, 或 Windows 容器，将应用完全隔离在一个受限的环境中。
• Java 模块系统（JPMS）：通过 module-info.java 在编译时和链接时控制 API 的可见性，提供了更强的封装和更少的运行时开销。
• 最小权限原则：以最低权限的用户身份运行 Java 进程，从根本上限制其对文件系统的访问能力。

7.3 FilePermission 的遗产

虽然不再用于运行时安全检查，但 FilePermission 的设计理念依然有价值：

• implies 模型：这种“蕴含”关系的思想，在更广泛的授权系统（如 OAuth scopes）中依然适用。
• 通配符路径匹配：其 * 和 - 的语义，被许多现代工具（如 .gitignore, Kubernetes RBAC）所借鉴。

---

第八章：总结——小权限，大历史

java.io.FilePermission 是 Java 平台发展史上的一座丰碑。它以其精巧的设计，成功地在近三十年的时间里，为无数 Java 应用提供了可靠的文件系统访问控制。其源码中蕴含的位掩码技术、双模式兼容策略、高效的路径蕴含算法以及智能的权限合并逻辑，都是值得我们学习和借鉴的软件工程杰作。

如今，随着 Security Manager 的谢幕，FilePermission 也完成了它的历史使命。它的废弃并非因为设计上的失败，而是因为整个软件安全范式的演进。它提醒我们，再优秀的技术，也需要与时俱进，适应新的时代需求。

对于今天的 Java 开发者而言，学习 FilePermission 的意义在于：

1. 理解历史：明白 Java 安全模型是如何演变的。
2. 汲取智慧：从其实现细节中学习高级的编程技巧和设计模式。
3. 面向未来：认识到现代安全实践的重点已转移到更底层、更高效的隔离机制上。

FilePermission 虽已老去，但其留下的思想光芒，仍将照亮 Java 平台未来的安全之路。它虽小，却是一部浓缩的 Java 安全史诗。