Linux openat2 resolve flags 怎样限制路径解析范围

openat2() 解决的核心问题不是“打开一个文件”这么简单，而是让程序能明确控制路径解析的边界：相对路径从哪个目录开始、能不能跟随符号链接、能不能跨挂载点。实际使用时，把目标目录先打开成 dirfd，再用 open_how.resolve 组合约束；需要拒绝越界时优先考虑 RESOLVE_BENEATH，需要把绝对路径也视为目录内路径时使用 RESOLVE_IN_ROOT。

先判断：dirfd 和 resolve 分别约束什么

openat2() 是 openat() 的扩展。相对路径会从 dirfd 指向的目录解析；如果传入绝对路径，默认会从系统根目录开始，除非同时使用 RESOLVE_IN_ROOT。所以，先拿到可信目录的文件描述符，再决定路径规则，比先拼接字符串再检查前缀更容易表达边界。

用 dirfd 和 open_how 建立稳定锚点

下面的示例演示一个“只在 /srv/app/data 内打开配置文件”的最小封装。man-pages 说明，glibc 没有直接提供 openat2() 包装，因此示例通过 syscall() 调用；open_how 必须先清零，size 传结构体大小。

#define _GNU_SOURCE
#include           // 读取系统调用失败原因
#include           // O_* 和 AT_FDCWD
#include   // RESOLVE_* 和 struct open_how
#include           // perror
#include     // SYS_openat2
#include          // close、syscall

static int open_under_data(const char *name) {
    // 先打开目录，后续相对路径都以它作为解析锚点
    int dirfd = open("/srv/app/data", O_PATH | O_DIRECTORY | O_CLOEXEC);
    if (dirfd == -1) {
        perror("open data directory");
        return -1;
    }

    // 清零保留字段，避免未来扩展字段带入随机值
    struct open_how how = {0};
    how.flags = O_RDONLY | O_CLOEXEC;
    how.resolve = RESOLVE_BENEATH | RESOLVE_NO_MAGICLINKS;

    // 使用相对路径，禁止通过 .. 越过 dirfd 指向的目录
    int fd = syscall(SYS_openat2, dirfd, name, &how, sizeof(how));
    int saved_errno = errno;
    close(dirfd);  // dirfd 只负责本次解析，完成后及时释放
    if (fd == -1) {
        errno = saved_errno;
        perror("openat2");
    }
    return fd;
}

这里的 RESOLVE_BENEATH 负责“不能离开目录”，RESOLVE_NO_MAGICLINKS 负责额外阻断 /proc 中常见的 magic link。若业务要求任何层级都不能出现普通符号链接，可以换成 RESOLVE_NO_SYMLINKS；但这会让原本依赖软链接的正常路径也返回错误，不能无差别开启。

按场景组合 resolve 标志，而不是堆满限制

如果你要处理来自归档包、用户配置或租户目录的相对路径，通常先明确“根”的语义，再增加链接和挂载约束。RESOLVE_BENEATH 更像后代检查：绝对路径和会跳出起点的 .. 不应成功。RESOLVE_IN_ROOT 则把 dirfd 作为本次调用的根，绝对符号链接也按该根解释，效果类似一次性的 chroot 路径解析，但不会改变进程的永久根目录。

// 只展示 resolve 字段的组合，flags 和 mode 仍按实际打开需求设置
struct open_how how = {0};
how.flags = O_RDONLY | O_CLOEXEC;

// 目录内路径：不越出锚点，同时拒绝符号链接和挂载点穿越
how.resolve = RESOLVE_BENEATH |
              RESOLVE_NO_SYMLINKS |
              RESOLVE_NO_XDEV;

// 如果业务允许绝对路径但要求它仍落在 dirfd 内，改用这一组
// how.resolve = RESOLVE_IN_ROOT | RESOLVE_NO_MAGICLINKS;

RESOLVE_NO_XDEV 会阻止跨 mount point，包括 bind mount；在容器、发行版升级或依赖系统路径的程序里，这个限制可能把原来可用的路径变成失败。因此应当把它作为明确的隔离需求，而不是默认的“安全开关”。

把失败映射到 errno，而不是只看返回值

openat2() 成功返回新的文件描述符，失败返回 -1 并设置 errno。将错误和标志对应起来，排障速度会比反复改路径字符串更快。

常见问题

RESOLVE_BENEATH 和 RESOLVE_IN_ROOT 可以同时使用吗？

实际设计中通常二选一：前者表达“必须是起点目录的后代”，后者表达“把起点当成本次解析的根”。先确定绝对路径和 .. 的业务语义，再选择更清晰的一种。

为什么设置了 NO_SYMLINKS 后原来的路径打不开？

它检查的是路径的所有组件，而 O_NOFOLLOW 主要影响最后一个组件。目录中任意一层出现符号链接都可能触发 ELOOP，应先查明链接是输入风险还是系统路径的正常组成。

openat2 能替代容器隔离吗？

不能。它只约束一次路径解析，不能提供完整的进程、网络、权限和资源隔离。把它当作文件访问边界的一层防护更准确。

落地时可以先固定 dirfd 语义，再逐项加入链接和挂载限制，并为 ELOOP、EXDEV、EAGAIN 保留可解释的错误路径。这样既能收紧不可信路径，也不会把所有失败都混成“文件不存在”。