SecurityManager不依赖继承链深度，而是基于调用栈在文件写操作时触发checkWrite进行运行时拦截。它通过检查所有调用者的权限上下文实现精准阻断，无论恶意子类继承多深或如何包装，只要最终调用FileOutputStream、Files.write等API，即被拦截。
Java SecurityManager 本身不直接识别“继承链深度”，它只在敏感操作发生时（如调用 FileOutputStream 构造、Files.write 等）触发权限检查，检查依据是当前执行栈中**所有调用者的代码源和权限上下文**，而非类的继承层级。因此，限制“深层继承链中的恶意子类写文件”，关键不是追踪继承几层，而是确保：无论子类多深、包装多绕，只要最终触发了文件写行为，checkWrite 就能拦截。
核心机制：基于调用栈的运行时检查
SecurityManager 的设计哲学是“守门人”而非“谱系审查员”。它不解析类结构或继承关系，而是在 JVM 执行到受保护操作（例如 new FileOutputStream(...)）时，自动调用 checkWrite(String file)，并传入目标路径。此时 JVM 已将完整调用栈（包括最外层用户代码、中间工具类、底层 JDK 类）提供给安全管理器。
- 你重写的
checkWrite方法可访问当前线程的全部调用栈（通过Thread.currentThread().getStackTrace()可辅助调试，但非必需） - 真正起作用的是：只要该方法抛出
SecurityException，JVM 就立即中断操作，不管调用者是MyApp、UtilsHelper还是EvilSubSubSubClass - 即使恶意类继承了 10 层、用了反射或动态代理调用写操作，只要最终落入 JVM 文件 I/O 路径，
checkWrite必然被触发
自定义 SecurityManager 精准拦截写操作
只需覆盖 checkWrite，无需关心继承深度。以下是最简有效实现：
public class StrictFileWriteBlocker extends SecurityManager {
@Override
public void checkWrite(String file) {
// 拦截所有写操作（也可加路径白名单逻辑）
throw new SecurityException("禁止任何文件写入，拒绝来自: " +
(file != null ? "路径[" + file + "]" : "空路径"));
}
// 可选：同时拦截文件删除、创建等关联操作
@Override
public void checkDelete(String file) {
throw new SecurityException("禁止文件删除");
}
}
启用方式（推荐启动参数，避免代码中误设）：
立即学习“Java免费学习笔记（深入）”；
java -Djava.security.manager -Djava.security.policy==/dev/null MyApp
注意：policy==/dev/null 表示不加载任何显式权限，让自定义 SecurityManager 全权裁决；若需部分放行（如仅允许写临时目录），则配合策略文件使用。
搭配策略文件实现细粒度白名单
若需允许特定路径写入（如仅限 /tmp/sandbox/），应结合 policy 文件与自定义检查：
- 策略文件
allow-tmp-write.policy内容：
grant {
permission java.io.FilePermission "/tmp/sandbox/-", "write,read,delete";
};
- 自定义管理器中保留策略检查（调用父类）+ 额外校验：
@Override
public void checkWrite(String file) {
// 先走标准策略检查（会根据 policy 文件判断是否授权）
super.checkWrite(file);
// 再加一层业务规则：禁止写入 /etc/、/root/ 等敏感路径
if (file != null && (file.startsWith("/etc/") || file.startsWith("/root/"))) {
throw new SecurityException("敏感系统路径禁止写入: " + file);
}
}
启动命令：
java -Djava.security.manager -Djava.security.policy=allow-tmp-write.policy MyApp
为什么不用依赖继承分析？
试图通过 getClass().getSuperclass() 或遍历 getDeclaredClasses() 来判断“是否为深层子类”，既不可靠也不安全：
- 恶意代码可使用
Unsafe、字节码生成（ASM）、模块层绕过等手段规避反射检查 - 继承链可能跨模块、跨类加载器，
Class对象比较易失效 - JVM 安全模型的设计原则是“最小权限 + 运行时阻断”，而非“静态结构审计”
- SecurityManager 的废弃（自 Java 17 起标记为 deprecated，Java 21 后移除）也正因其耦合过重、难以维护，现代方案倾向沙箱容器（如 JVM 隔离进程）或语言级限制（如密封类+模块系统）
