文件操作安全：别让文件成为你的突破口

文件操作，听起来很基础对吧？

但说实话，我见过太多项目栽在这上面。有个同事曾经跟我吐槽，说他们产品上线第一天就被黑了——原因就是临时文件路径写死了。嗯，这种坑我踩过不止一次。

今天咱们就聊聊文件操作安全的五个关键点。每个点我都会结合自己的实战经验来讲。

1. 文件路径安全：别让黑客“越狱”

文件路径安全的核心是什么？说白了就是防止路径遍历攻击。

攻击者会尝试用 ../../../etc/passwd 这样的路径，跳出你设定的目录。我早期做的一个Web服务就中过招——用户上传头像时，文件名里带了 ../，结果文件被写到了系统目录下。

• 绝对不要信任用户输入的文件名。哪怕它看起来人畜无害。
• 用规范化的路径函数。比如 C++17 的 std::filesystem::canonical()，或者 POSIX 的 realpath()。

// 错误示范：直接拼接
std::string path = "/data/uploads/" + user_filename;

// 正确做法：规范化后再检查
std::filesystem::path base = "/data/uploads";
std::filesystem::path full = base / user_filename;
full = std::filesystem::weakly_canonical(full);

// 检查是否还在允许的目录内
if (full.string().find(base.string()) != 0) {
    throw std::runtime_error("非法路径");
}

你想想看，如果攻击者传个 ../../etc/passwd，第一种写法就直接把系统文件暴露了。第二种写法至少能拦住大部分攻击。

2. 临时文件安全：别留下“犯罪证据”

临时文件的问题，我印象最深的是有一次做日志分析工具。程序跑完，临时文件忘了删，结果里面全是敏感数据。

临时文件的安全要点有三个：

• 使用安全的临时目录。Linux 下用 /tmp 或 /dev/shm，Windows 下用 GetTempPath()。
• 生成不可预测的文件名。别用 temp_1.txt 这种，用 mkstemp() 或 tmpfile()。
• 用完立即删除。最好用 RAII 封装，析构时自动清理。

#include <filesystem>
#include <cstdio>

class TempFile {
    std::filesystem::path path_;
public:
    TempFile() {
        char name[] = "/tmp/myapp_XXXXXX";
        int fd = mkstemp(name);
        if (fd == -1) throw std::runtime_error("创建临时文件失败");
        close(fd);
        path_ = name;
    }
    ~TempFile() {
        if (!path_.empty()) {
            std::filesystem::remove(path_);
        }
    }
    // 禁止拷贝，允许移动
};

我个人习惯用这种 RAII 方式。你想想看，如果异常发生时忘记清理，临时文件就会一直留在磁盘上。用 RAII 至少能保证析构时清理掉。

3. 文件权限管理：别把钥匙挂在门上

文件权限这个事，说起来简单，做起来容易翻车。

我记得有一次帮客户做安全审计，发现他们的配置文件权限是 0777——任何人都能读写。问原因，开发说“方便调试”。嗯，方便是方便了，但攻击者也方便了。

场景	推荐权限	说明
配置文件	0600	只有所有者能读写
日志文件	0640	所有者和组可读，组可追加
可执行文件	0755	所有者可写，其他人可执行
共享数据	0660	所有者和组可读写

在 C++ 中设置权限，Linux 下用 chmod()，Windows 下用 SetFileSecurity()。C++17 的 std::filesystem::permissions() 可以跨平台处理。

#include <filesystem>

// 设置文件为仅所有者可读写
std::filesystem::permissions("config.ini",
    std::filesystem::perms::owner_read | std::filesystem::perms::owner_write,
    std::filesystem::perm_options::replace);

4. 文件描述符泄漏：别让资源“蒸发”

文件描述符泄漏，说白了就是打开文件后忘了关。一次两次没事，但泄漏多了，进程就会达到上限，然后所有文件操作都失败。

我遇到过最夸张的一次，一个后台服务跑了三天，文件描述符从几十涨到几万。最后连日志都写不进去了——因为日志文件本身也需要文件描述符。

解决这个问题，我推荐两个方法：

• RAII 封装：用类管理文件描述符，析构时自动关闭。
• 智能指针 + 自定义删除器：适合需要共享文件描述符的场景。

#include <memory>
#include <unistd.h>

// 自定义删除器
struct FileDeleter {
    void operator()(int* fd) {
        if (fd && *fd >= 0) {
            close(*fd);
            delete fd;
        }
    }
};

// 使用智能指针管理
auto fd = std::unique_ptr<int, FileDeleter>(new int(open("data.txt", O_RDONLY)));

// 或者更简单的 RAII 类
class FileHandle {
    int fd_;
public:
    FileHandle(const char* path) : fd_(open(path, O_RDONLY)) {
        if (fd_ < 0) throw std::runtime_error("打开文件失败");
    }
    ~FileHandle() { if (fd_ >= 0) close(fd_); }
    // 禁止拷贝
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
};

你想想看，如果每个文件操作都手动配对 open/close，出错的概率有多大？用 RAII 至少能保证异常安全。

5. 文件锁定与竞态条件：别让并发“打架”

竞态条件，这是文件操作里最难搞的问题之一。

两个进程同时写同一个文件，会发生什么？数据错乱、内容覆盖、甚至文件损坏。我见过一个数据库应用，因为没做文件锁定，结果索引文件被两个线程同时写，最后整个库都重建了。

文件锁定有两种方式：

• 建议性锁：靠进程自觉遵守，Linux 的 flock() 和 fcntl() 都属于这类。
• 强制性锁：操作系统强制实施，但性能开销大，不常用。

#include <sys/file.h>
#include <unistd.h>

int fd = open("data.lock", O_CREAT | O_RDWR, 0666);
if (fd < 0) {
    // 处理错误
}

// 尝试获取独占锁
if (flock(fd, LOCK_EX | LOCK_NB) == 0) {
    // 获取锁成功，可以安全操作文件
    // ...
    
    // 释放锁
    flock(fd, LOCK_UN);
} else {
    // 获取锁失败，其他进程正在操作
    // 可以等待或返回错误
}

我个人习惯用 fcntl() 的记录锁，因为它可以锁定文件的一部分，粒度更细。而且 fcntl() 的锁与进程关联，进程退出时自动释放，不容易死锁。

知识体系总览

下面这张图，是我梳理的文件操作安全知识体系。你可以把它当作一个检查清单，每次做文件操作时对照一下。

这张图把五个知识点串起来了。你写代码的时候，可以对照着检查：路径安全了吗？临时文件清理了吗？权限设对了吗？描述符关了吗？并发操作加锁了吗？

嗯，文件操作安全就聊到这儿。这些经验都是我用真金白银换来的，希望能帮你少踩一些坑。

---

公众号:蓝海资料掘金营，微信deep3321