Java Files.createTempFile 怎样预设 POSIX 文件权限

我第一次把 Java 临时文件用于保存短暂的凭据材料时，最在意的不是文件名，而是文件刚出现的那一刻有没有暴露给同机其他用户。Files.createTempFile 本身支持可变参数 FileAttribute>...，所以在支持 POSIX 属性的文件系统上，可以把权限随创建操作一起传入，而不是先创建一个文件再补一次 chmod。

本文只讨论 POSIX 文件权限，不展开 ACL。核心写法是：先用 PosixFilePermissions.fromString("rw-------") 得到权限集合，再用 asFileAttribute 包装，最后传给 createTempFile。

先分清两个 createTempFile 重载

不指定目录时，Java 会在默认临时文件目录创建文件；指定 Path 时，文件会落在传入目录所在的文件系统中。两种重载都接收属性参数，文件名仍由实现生成，prefix 和 suffix 只是候选名的一部分，不能把它们当成权限配置。

把 rw------- 变成创建属性

PosixFilePermissions.fromString 接受九字符权限串，顺序是所有者、组、其他用户。临时文件通常先从最小权限开始，例如 rw------- 表示只有所有者可读写，不给组和其他用户任何权限。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.FileAttribute;
import java.nio.file.attribute.PosixFilePermissions;

public class SecureTempFile {
    public static Path createPrivateTempFile() throws IOException {
        // 先把九字符权限串转换成 POSIX 权限集合。
        var permissions = PosixFilePermissions.fromString("rw-------");
        // 把权限集合包装成 createTempFile 能接收的文件属性。
        FileAttribute> attribute = PosixFilePermissions.asFileAttribute(permissions);
        // 属性随创建调用传入，避免先创建再补权限的空档。
        return Files.createTempFile("job-", ".data", attribute);
    }
}

这里的关键不是 FileAttribute 变量本身，而是它出现在创建调用的最后一个参数位置。Oracle API 将这类属性定义为创建新文件时要原子设置的可选属性；因此不需要把“先创建、再修改权限”当成标准流程。

指定工作目录时，把目录边界也写清楚

如果临时文件会被某个服务读取，实际项目通常应该显式选择工作目录，而不是完全依赖系统默认目录。下面的示例仍然沿用同一份权限属性，同时在完成后删除文件。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.FileAttribute;
import java.nio.file.attribute.PosixFilePermissions;

public class TempFileInWorkDir {
    public static void run(Path workDir) throws IOException {
        // 只允许当前所有者读写，避免把临时内容开放给同组用户。
        FileAttribute> privateMode = PosixFilePermissions.asFileAttribute(
                PosixFilePermissions.fromString("rw-------"));
        Path temp = Files.createTempFile(workDir, "payload-", ".bin", privateMode);
        try {
            // 这里写入和读取临时内容；真实代码应按需限制内容生命周期。
            Files.writeString(temp, "temporary data");
        } finally {
            // 任务结束后清理，避免敏感临时文件长期留在工作目录。
            Files.deleteIfExists(temp);
        }
    }
}

删除动作与权限设置是两件事：前者负责生命周期，后者负责创建瞬间的访问边界。若文件需要交给另一个明确的进程读取，应按实际协作关系调整权限，而不是直接放宽到 rw-rw-rw-。

迁移时要处理的三个边界

第一，POSIX 不是所有文件系统都支持。 如果文件系统提供者不能原子设置这类属性，调用可能抛出 UnsupportedOperationException。这不是权限字符串写错，而是当前存储不提供对应能力。跨平台代码应把 POSIX 分支和非 POSIX 分支分开设计，不能假设 Windows 或自定义文件系统也有同样的权限模型。

第二，权限字符串本身也会失败。 fromString 需要九个位置的 r、w、x 或 -，例如把八字符或带数字的模式直接传入会得到 IllegalArgumentException。这类错误应在配置加载阶段发现，不要等到业务写临时文件时才猜原因。

第三，目录权限和文件权限不是一回事。 文件即使是 rw-------，父目录仍可能允许其他用户枚举文件名或删除目录项。涉及敏感材料时，目录本身也要由部署方案控制；本文的 FileAttribute 只负责新文件的 POSIX 属性。

我的迁移清单

• 把临时文件创建统一收口到一个方法，集中定义权限和前后缀。
• 在支持 POSIX 的部署环境传入 PosixFilePermissions.asFileAttribute，不要创建后再补权限。
• 如果目录必须固定，使用带 Path 的重载，并在启动阶段检查目录存在性与写权限。
• 用 try/finally 或等价的生命周期策略清理临时文件；不把删除责任留给调用者的“记得清理”。
• 对非 POSIX 文件系统明确采用平台原生权限方案，或在功能边界上说明不提供同等保证。

如果你的目标只是生成一个短生命周期工作文件，最小可用方案就是“权限集合 → FileAttribute → createTempFile”。如果还涉及跨进程共享、目录隔离或跨平台部署，就要把目录模型和能力探测一起纳入迁移设计。

相关问题

不传 FileAttribute 时，临时文件一定是 600 吗？

不要把具体数字权限写死成跨平台保证。Java 文档说明未指定属性时，临时文件可能比旧式 File.createTempFile 创建的文件更严格；需要明确权限时应显式传入属性，并结合目标文件系统的能力。

为什么不能创建后再调用 setPosixFilePermissions？

创建后再修改会多一个中间状态。若权限边界从创建瞬间就重要，应优先通过 FileAttribute 在创建调用中设置；只有在创建时无法设置的环境下，才考虑后续修改并接受相应风险。