SecureDirectoryStream 并非 Java 标准 API，而是云原生沙箱通过拦截 DirectoryStream 调用、绑定执行上下文及动态路径校验实现的扩展机制，依赖命名空间隔离、SecurityManager 和 OS 层 MAC 三重防护。
Java NIO.2 的 SecureDirectoryStream 并不是标准 JDK 中的公开 API 类——它并不存在于 Java SE 规范或 OpenJDK 实现中。这是关键前提。所谓“SecureDirectoryStream”是部分云原生安全增强型运行时（如某些定制 JVM 或沙箱容器 SDK）为强化文件系统隔离而引入的**扩展抽象**，并非 Java 原生能力。在严苛云原生沙箱中，真正起效的是对 java.nio.file.DirectoryStream 及其底层资源访问路径的**策略拦截与上下文绑定**，而非一个独立的“Secure”类。
它不靠新类，靠运行时拦截和上下文绑定
标准 NIO.2 提供 Files.newDirectoryStream(Path)，返回普通 DirectoryStream<path></path>。云原生沙箱（如基于 JVM Agent 或 eBPF 辅助的容器运行时）不会替换这个接口，而是：
- 在
Path构造或解析阶段注入访问控制逻辑，例如拦截Paths.get("/etc/shadow")并立即拒绝 - 将每个打开的
DirectoryStream实例与调用方的执行上下文（如 Pod UID、ServiceAccount、任务角色）强绑定 - 在每次
iterator().next()或forEach()遍历时，动态校验当前条目是否落在该上下文被授权的路径前缀内（如只允许读取/workspace/**）
越权防护依赖三重加固机制
单纯依赖 NIO.2 接口无法防越权。有效防护需组合以下层：
-
命名空间隔离：容器 rootfs 已挂载为只读或仅暴露
/app和/tmp，DirectoryStream即便构造成功也查不到敏感路径 -
SecurityManager + Policy（若启用）：对
FilePermission的"read"请求做细粒度检查，例如只允许"./config/*.json"，拒绝"/proc/self/environ" -
OS 层强制访问控制（MAC）：如 SELinux 或 AppArmor 策略，直接阻断进程对非授权目录的 openat() 系统调用，NIO.2 层面甚至收不到错误，而是抛出
AccessDeniedException
开发者必须主动配合的实践
再强的沙箱也无法自动识别业务语义。要真正防住越权，代码本身需遵循最小权限原则：
立即学习“Java免费学习笔记（深入）”；
- 避免拼接用户输入构造
Path，改用白名单路径模板 +Path.resolve() - 使用
Files.isReadable()和Files.isDirectory()前，先校验路径是否属于预期根目录（如userRoot.resolve(path).startsWith(userRoot)） - 禁用递归遍历（
Files.walk()），改用受限深度的DirectoryStream+ 显式路径白名单
替代方案比“SecureDirectoryStream”更现实
与其等待某个未标准化的“Secure”类，不如采用已被验证的工程实践：
- 用
java.nio.file.FileSystem的自定义实现封装所有 I/O，统一做路径归一化与授权检查 - 在 Spring Boot 等框架中，通过
@ControllerAdvice拦截所有文件操作异常，并记录越权尝试日志 - 借助 SPI（Service Provider Interface）注册可信
PathFilter，在流创建时注入业务级过滤逻辑
