别再把 MCP Roots 当安全沙箱：一个符号链接就能逃逸目录

我最近重新检查了一个 MCP 文件服务器实现。

客户端已经让使用者选择了工作区，Server 也拿到了 Roots。表面上看，模型只能操作这个目录，边界似乎已经够清楚。

真正做方法测试时问题马上出来了：

workspace/
├── docs/
├── drafts/
└── latest-log -> /Users/me/.ssh/

请求读取的参数只有：

latest-log/config

输入里没有 ../也不是绝对方法，但符号链接解析后真实目标已经离开工作区。

这也是 MCP 文件服务器最容易被误解的地方：

如果 Server 只检查原始字符串。或者只判断客户端是否提供了 Root，这次读取仍可能被放行。

一个安全请求应该经过哪些检查

更准确的边界关系应该是：

使用者选择可访问目录
↓ Client 通过 Roots 声明候选边界
↓ 拒绝绝对方法
↓ resolve / realpath 解析 .. 与符号链接
↓ 校验真实方法仍属于授权 Root
↓ 检查敏感目录、文件类型、大小和读写策略
↓ Resource / Tool 权限控制
↓ 低权限使用者或容器形成最终物理边界

Roots 能告诉 Server 当前工作区在哪里但它不会自动替你完成这些事：

• 拒绝绝对方法；
• 消解 ..；
• 解析符号链接；
• 阻止读取 .ssh.env 和凭据目录；
• 限制文件大小和返回长度；
• 限制写入只能进入草稿目录；
• 记录谁调用了哪个 Tool、操作了什么方法。

这些仍然是 Server 的职责。

为什么字符串前缀判断不可靠

不少实现会写成这样：

from pathlib import Path
ROOT = Path.resolve
def unsafe_path -> Path:
target = ROOT / user_path
if not str.startswith):
raise ValueError
return target

This code has at least two problems:

• The concatenated path is never resolved. Symbolic links can point outside root.
• A string prefix check is not a directory‑ownership test. For example,/workspace-safe would pass check even though it’s outside intended root.

I prefer to centralise path validation into a single helper that every Resource and Tool must use:

from pathlib import Path
class PathRejected:
pass
def resolve_inside -> Path:
candidate = Path
if candidate.is_absolute:
raise PathRejected
# Resolve symlinks and .. components in one go.
target = .resolve
从try来看，target.relative_to
except ValueError as exc:
raise PathRejected from exc
return target

The crucial part is not how many lines of code you write,but order of checks:

只接受相对方法 → resolve / realpath → relative_to 判断真实目录归属 → 检查敏感目录、类型和大小 → 再执行读写

不要看起来安全。要用攻击方法验证

Create a normal file and a symlink that points outside of sandbox:

mkdir -p sandbox/docs
printf "ok"> sandbox/docs/readme.md
ln -s ~/.ssh sandbox/latest-log

Then run four test cases:

ROOT = Path.resolve
cases =
for relative_path in cases:
从try来看，target = resolve_inside
print
except PathRejected as exc:
print

输入	结果	原因
docs/readme.md	ALLOWED	真实方法仍在 Root 内部
}	REJECTED	规范化后越过 Root
/etc/passwd}	REJECTED	绝对方法被禁止 latest- log/ config`}	REJECTED < td style= "text- align: left;"> 符号链 接 解 析 后 指 向 Root 外 部 < / t r>

T​O​C​T​O​U 竞态要注意的细节

需要进一步使用  配合 dir_fd 或 O_NOFOLLOW，甚至直接在容器中只读挂载，以把校验与打开绑定在同一权限边界上。 说起来，

Resource、Tool、Prompt 不要混成一个万能接口

另一个常见问题。是为了省事注册三个能力过大的 Tool ：

read_any_file
write_any_file
run_command

它们开发起来很快，但模型一旦生成错误参数，影响范围也是最大的。

说到更稳的拆法是。

• Resource：读取可标识、相对稳定的上下文，例如 README 、配置快照、日志片段。
• Tool：执行查询、计算或有副作用的动作。
• Prompt：使用者主动选择的任务模板，例如 “检查当前配置” 或 “指定日志”。
• Root：Client 告知 Server 的文件程序候选边界。话说回来，

对应到接口。可以收窄成：

read_text
write_draft
propose_patch

写正式内容、删除文件、移动目录和输入命令，不应该因为 “已经接入 MCP” 就默认开放。

stdio 还有一个比较容易踩的坑

stdio 模式下stdout 是协议通道。

下面两行普通日志都可能让客户端报 – Parse error  ：

print

console.log

业务日志应该显式写入 stderr 或独立日志文件。

• 不要为了拦截第三方输出，直接覆盖 process.stdout.write。
• 也不要粗暴执行 sys.stdout = sys.stderr。
• MCP SDK 自己也需要 stdout 返回合法消息，这种兜底可能把正常协议响应一起破坏。

本地 stdio 和远程 Streamable HTTP 怎么选

---