Go os.Root 相对路径校验为什么仍然失败怎样构造最小复现

os.Root 的“相对路径”是相对于已经打开的根目录，而不是相对于当前工作目录，也不是把根目录绝对路径再拼到参数里。最常见的失败有三种：把 root.Name() 拼进 Root.Open 形成绝对路径，把空字符串传进去，或者让 .. 走出根目录。修复方式是保留调用方的根内相对名称，让 Root 负责目录边界判断，并用 *os.PathError 记录真实原因。

官方文档：https://pkg.go.dev/os#Root

实现参考：https://go.dev/src/os/root.go

先分清根目录和传入路径

调用 os.OpenRoot 时传入的是要保护的目录；调用 root.Open 时传入的是这个目录里面的名称。例如根目录是 /srv/app-data，合法输入可以是 configs/app.yaml，而不是 /srv/app-data/configs/app.yaml。后者看起来指向同一个文件，但对 Root.Open 来说已经是绝对路径。

这套 API 的保护对象是“目录树内访问”。根对象的方法会阻止绝对路径、空路径以及解析后逃出根目录的路径；符号链接可以被跟随，但不能把目标带到根目录之外。它不等同于把任意字符串先 filepath.Clean 一遍，也不等于当前工作目录的沙箱。

用最小复现固定失败边界

排查时先不要把文件不存在、权限不足和路径越界混在一起。下面的示例只构造调用关系，重点是查看每个输入交给 Root.Open 后的错误类型。示例没有依赖具体机器路径，真正项目中可以把临时目录替换成受控的数据目录。

package main

import (
    "fmt"
    "os"
    "path/filepath"
)

func probe(rootDir string) {
    root, err := os.OpenRoot(rootDir)
    if err != nil {
        fmt.Printf("open root: %v\n", err)
        return
    }
    defer root.Close() // 根对象持有目录句柄，结束后要释放资源。

    cases := []string{
        "inside/config.yaml",             // 根目录内的相对名称。
        "",                               // 空名称会被拒绝。
        "../outside.txt",                 // 试图从根目录向上逃逸。
        filepath.Join(root.Name(), "x"),  // 拼出绝对路径，不是 Root 所需的名称。
    }
    for _, name := range cases {
        file, err := root.Open(name)
        if err != nil {
            fmt.Printf("name=%q err=%v\n", name, err) // 保留原始错误，便于区分边界。
            continue
        }
        file.Close() // 这里只验证打开结果，成功句柄也要立即关闭。
        fmt.Printf("name=%q opened\n", name)
    }
}

func main() {
    probe("/srv/app-data") // 生产环境应传入明确的受控根目录。
}

这里的关键不是记住某一条错误字符串，而是看输入属于哪一类。filepath.Join(root.Name(), "x") 产生的结果带有根目录绝对前缀；../outside.txt 则要求访问根目录之外的对象。两者都不应通过给参数再加一层目录字符串来“修正”。

从 PathError 判断是哪一层失败

建议使用 errors.As 提取 *os.PathError，把操作名、用户输入和根对象名称写进诊断记录，但不要把内部绝对路径直接回显给外部用户。错误字符串适合日志阅读，程序判断应优先使用错误类型和业务字段。

按根相对语义修复调用方

修复的核心是让函数接口明确接收“根内相对名称”，不要让调用方把物理目录拼进来。对空值和明显的绝对路径可以在业务层尽早给出友好提示，但不要用一套字符串清洗逻辑替代 Root 的边界保护，尤其不要把越界输入悄悄改成另一个文件名。

func readUnderRoot(rootDir, name string) ([]byte, error) {
    if name == "" {
        return nil, fmt.Errorf("文件名不能为空") // 业务层先拒绝空输入。
    }

    root, err := os.OpenRoot(rootDir)
    if err != nil {
        return nil, fmt.Errorf("打开受控根目录: %w", err)
    }
    defer root.Close() // 无论读取成功还是失败都释放根对象。

    file, err := root.Open(name) // 这里只传根内相对名称。
    if err != nil {
        var pathErr *os.PathError
        if errors.As(err, &pathErr) {
            return nil, fmt.Errorf("拒绝访问 %q: %w", name, err) // 保留 PathError 供上层判断。
        }
        return nil, err
    }
    defer file.Close() // 文件句柄与 Root 分别管理，不能遗漏任一方。

    data, err := io.ReadAll(file)
    if err != nil {
        return nil, fmt.Errorf("读取 %q: %w", name, err)
    }
    return data, nil
}

这段代码需要导入 errors、fmt、io 和 os。它没有把绝对根目录暴露给 Root.Open，也没有把 ../ 变成看似安全的另一个名字。若业务允许用户选择子目录，应把选择结果限制为明确的根内名称，再交给 Root 做最终的目录边界判断。

上线前核对哪些边界

• 根目录只在初始化时解析一次，后续调用统一使用根内相对名称。
• 空输入、绝对路径、Windows 盘符或卷相关路径都单独记录，不用当前工作目录猜测。
• 对 .. 和符号链接逃逸保留失败事件，不能为了成功读取而自动换目标。
• 读取完成后同时关闭文件和 Root，并在日志中保留错误类型而非只保留错误文本。
• 测试时至少覆盖根内文件、根外文件、根内指向根外的符号链接和不存在目标。

相关问题

把 root.Name() 和文件名拼起来再传给 root.Open 可以吗？不可以。那会把根目录绝对路径重新放进 Root 方法参数，应该只传根相对名称。

filepath.Clean 能代替 os.Root 做安全校验吗？不能。它只做字符串规范化，不能代替对符号链接和实际目录边界的保护。

根内的符号链接一定能打开吗？不一定。链接可以被跟随，但目标不能位于根目录之外；跨出边界时应把失败当作保护结果。