【免费下载链接】WASIWebAssembly System Interface项目地址https://gitcode.com/gh_mirrors/wa/WASI点击查看免费下载导读WASIWebAssembly System Interface的文件系统接口采用能力导向capability-oriented的沙箱设计所有路径访问都通过基础目录句柄base directory handle 相对路径进行路径解析被严格限制在句柄所引用的子文件系统内。本文以仓库中的 path-resolution.md 为骨架系统讲解该沙箱方案的设计原理、符号链接处理规则、基于openat/readlinkat的手动解析算法以及 Linuxopenat2、WindowsNtCreateFile等宿主实现优化路径。读完本文你将理解 WASI 文件系统无全局命名空间、无绝对路径的安全边界是如何在操作系统原语之上构建的并能自行评估与实现类似的受约束路径解析逻辑。一、设计渊源从 CloudABI 与 Capsicum 到 WASI 沙箱WASI 文件系统的路径沙箱方案在 proposals/filesystem/path-resolution.md 中明确说明其模型仿照 CloudABI 使用的系统并与 FreeBSD 的 Capsicum 能力安全框架类似。这一脉络与 WASI 的整体设计理念一脉相承——docs/DesignPrinciples.md 中写道WASI 基于能力安全capability-based security原则设计所有对外部资源的访问都以能力形式提供docs/Capabilities.md 进一步区分了链接期能力link-time capabilities即函数与运行期能力runtime capabilities即句柄并指出同时打开多个文件的场景天然需要句柄形式的运行期能力。具体到操作系统语义的对应关系原文档给出了两个内核层面的直接映射平台对应原语说明Linuxopenat2的RESOLVE_BENEATH行为内核对路径解析进行禁止越出基准目录的约束FreeBSDopen的O_RESOLVE_BENEATH行为同样是内核级仅允许在基准目录之下解析的旗标值得注意的是原文档特别强调路径解析并不依赖这些内核扩展才能实现也可以使用openat和readlinkat或类似原语手工实现。这意味着沙箱语义既可以借助内核能力高效落地也可以在缺少对应内核支持的系统上通过用户态算法复现——这正是后文手动解析算法存在的意义。二、沙箱总览只有句柄 相对路径没有全局命名空间原文档对沙箱的整体约束给出了非常明确的定义这是理解整个文件系统安全模型的核心所有操作文件系统路径的函数都接收一对值一个基础目录句柄 一个相对路径。绝对路径不被允许并且不存在全局命名空间。所有路径访问都相对于某个基础目录句柄进行。路径解析被约束在基础句柄所引用的子文件系统之内。句柄之外的文件系统信息不可见。特别地不允许使用类似../../../stuff/here的路径临时越出沙箱再折返哪怕最终解析结果落回沙箱内——因为这会泄露沙箱外部目录的存在性信息。这条禁止临时越界的规则很容易被忽略但它恰恰是防信息泄露的关键如果允许../先跳出再跳回攻击者可以通过是否报错来探测沙箱外目录是否存在从而把沙箱变成一台信息侧信道探测机。原文档还强调了一个重要的设计目标即使存在外部进程并发访问同一文件系统包括重命名、取消链接、新建文件和目录沙箱仍然必须可正确实现。也就是说沙箱不能依赖文件系统是静态的、只有 WASI 程序自己在操作这类假设。在 WIT 定义中的落实上述规则在仓库的 WITWebAssembly Interface Type源码中有直接体现。打开 proposals/filesystem/wit/types.wit 可以看到包名wasi:filesystem0.3.1接口注释明确写道All paths in WASI are relative paths, and are interpreted relative to adescriptorreferring to a base directory.违规时的错误码被明确规定如果某个path参数以/开头或解析路径的任何一步包括..和符号链接步骤到达了基础目录之外或到达了指向底层文件系统中绝对/有根路径的符号链接则函数以error-code::not-permitted失败。目录分隔符在 WASI 中始终是正斜杠/路径作为string传递由 Unicode 标量值USVs构成。与路径解析直接相关的类型还包括path-flags目前只有一个成员symlink-follow用于控制路径解析过程中是否展开符号链接对应 POSIX 中open等调用默认跟随符号链接的行为由调用方显式声明。open-flagscreate类似O_CREAT、directory类似O_DIRECTORY、exclusive类似O_EXCL、truncate类似O_TRUNC。descriptor-flagsread、write、mutate-directory目录内容可变性未设置时创建、重命名、删除、修改数据或元数据等操作将失败并返回read-only等。error-code与 POSIXerrno对齐的完整错误码枚举其中与路径沙箱直接相关的有not-permitted对应EPERM、loop对应ELOOP符号链接层级过多、access对应EACCES等。这些标志与下文的手动解析算法配合构成了完整的受约束打开语义。此外proposals/filesystem/wit/preopens.wit 中的get-directories函数返回预打开目录preopened directories集合及其路径它是程序在启动时获得初始基础目录句柄的通道整个导入集在 proposals/filesystem/wit/world.wit 中声明import types; import preopens;配套的 HTML 版接口文档见 proposals/filesystem/imports.md。三、符号链接的沙箱规则创建宽松、访问严格符号链接是路径沙箱中最容易出问题的环节原文档给出了两条相辅相成的规则规则 1创建时的限制。用绝对路径字符串创建符号链接会失败返回not-permitted错误。除此之外只要底层文件系统实现支持符号链接可以被创建为任意字符串。这一点在 proposals/filesystem/wit/types.wit 的symlink-at函数注释中同样有明文Ifold-pathstarts with/, the function fails witherror-code::not-permitted.对应的readlink-at注释也规定若链接内容包含底层文件系统中的绝对或有根路径读取失败并返回not-permitted。规则 2访问时的严格检查。对符号链接字符串的沙箱化检查发生在路径被解析访问的时刻而不是在符号链接被创建或移动的时刻。这样做的目的是即便沙箱外部拥有文件系统访问权限的其他实体创建或重命名了符号链接沙箱依然能得到遵守。这两条规则的组合含义是深刻的符号链接本身只是文件系统中的一个数据对象可以任意写入真正的安全闸门在解析这一步。只要解析过程对绝对路径、..越界、指向沙箱外部的链接一律拒绝那么无论沙箱内外谁创建了符号链接都无法成为逃逸工具。这也是路径解析必须在每次访问时重新执行沙箱检查的根本原因——不能依赖创建时的检查结果因为创建者可能不是 WASI 程序甚至可能是恶意内容。四、宿主实现用openatreadlinkat手工实现路径解析4.1 为什么裸openat不够原文档指出朴素的openat不执行任何沙箱化它会直接打开包含..或以/开头的路径也会跟随指向这类路径的符号链接。它虽然提供了O_NOFOLLOW旗标但该旗标只作用于路径的最后一个组件例如a/b/c中的c。如果沙箱直接调用openat打开a/b/c中间组件a、b若是符号链接仍可能被跟随而越出沙箱。因此手工实现沙箱的策略是把路径拆分为组件如a、b、c一次只打开一个组件这样每个组件都可以用O_NOFOLLOW打开从而逐级约束解析范围。4.2 完整的手工解析算法原文档给出了算法的关键分支逻辑可以整理成如下伪代码流程components split(path, /) # 将相对路径拆分为组件列表 base_fd 基础目录句柄 while components 非空: component components.pop(0) # 取出最前面的一个组件 if component ..: if components_consumed 为空: # 试图用 .. 越过沙箱根 失败返回 access denied else: 回退一层pop 掉已消费的组件栈中的一个 else: fd openat(base_fd, component, O_NOFOLLOW) if fd 失败且错误码表明是符号链接如 ELOOP: link readlinkat(base_fd, component) # 读取链接内容 if link 以 / 开头: # 指向绝对路径 失败返回 access denied else: 把 link 拆分出的组件前插到 components 前面 # 注意不推进 base_fd继续解析链接内容 elif fd 失败: 按常规错误码处理 else: base_fd fd # 成功打开前进一步 记录已消费组件算法要点总结如下均出自原文档openat失败且错误码表明目标是符号链接例如ELOOP时调用readlinkat读取链接内容把内容拆分为组件后前插到组件列表头部然后继续解析。链接内容以绝对路径开头时代表尝试跳出沙箱路径解析应以access denied错误失败。遇到..组件时不执行打开操作而是从组件列表已消费部分中弹出一个条目若列表已空则代表试图用..走出沙箱同样以access denied失败。这里有一个值得注意的细节O_NOFOLLOW只保护最后一个组件这一限制正是通过一次只打开一个组件的循环被绕过的——每个组件在它被打开的那一刻都处于最后位置因此都能得到O_NOFOLLOW的保护。而ELOOP错误码在这里充当了探测到符号链接的信号触发readlinkat的手工展开。这个算法虽然比直接openat慢但它不依赖任何内核扩展可以运行在任何提供openat/readlinkat的系统上。4.3 与 WIT API 的对应关系手工解析算法在 API 层的直接落点就是descriptor.open-at等函数。查看 proposals/filesystem/wit/types.wit 中open-at的定义open-at: async func( path-flags: path-flags, // 例如 symlink-follow path: string, // 相对路径 open-flags: open-flags, // create / directory / exclusive / truncate %flags: descriptor-flags, // read / write / mutate-directory 等 ) - resultdescriptor, error-code;其注释明确similar toopenatin POSIX且规定了权限放大约束若请求的标志含write、mutate-directory或open-flags含truncate、create而基础描述符未设置mutate-directory则open-at以read-only失败——这保证了基础句柄的权限不会通过一次打开操作被放大与路径沙箱共同构成双层防护。类似的stat-at对应fstatat、link-at对应linkat、readlink-at对应readlinkat、symlink-at对应symlinkat、rename-at对应renameat等函数都以相对路径 基础描述符的形式接受参数全部遵循同一套沙箱约束。五、平台实现笔记与优化手段原文档的Implementation notes一节给出了三个平台相关的实现思路5.1 Linuxopenat2RESOLVE_BENEATH/proc/self/fd在 Linux 上openat2配合RESOLVE_BENEATH可以作为优化手段使用。原文档特别指出这一组合不仅能优化单纯的open还能借助 Linux 的O_PATH与/proc/self/fd特性实现许多其他系统调用的沙箱化——即先以O_PATH方式获得一个指向目标对象的文件描述符再通过/proc/self/fd/N把它当作路径交给其他系统调用使用从而让非 open 类系统调用也能获得路径解析的沙箱保护。5.2 WindowsNtCreateFile充当openat在 Windows 上NtCreateFile函数可以接受目录句柄行为类似openat因此可以直接套用手工解析算法即本文第四章的流程在 Windows 上实现同样的逐组件约束解析。5.3 Rust 生态cap-stdRust 库cap-std实现了 WASI 的文件系统沙箱语义但它独立于 WASI 或 Wasm可以在其他场景中复用。原文档指出它使用了openat2、NtCreateFile及其他优化手段——即把各平台的加速方案封装在统一的能力化文件系统访问抽象之后。5.4 历史参考cloudabi-utils 的 C 语言实现cloudabi-utils 仓库中有一份手工解析算法manual technique的 C 语言实现可作为参考原文档注明该仓库已不再维护仅作借鉴之用。5.5 从源码结构可做的推断结合仓库现状可以从源码结构推断本仓库中的 proposals/filesystem 是提案的规格与测试占位proposals/filesystem/test/README.md 中的测试指南尚待填充实际宿主实现如openat2、NtCreateFile的封装位于提案所指向的独立实现仓库例如 cap-std 生态中而非本仓库内。因此涉及具体实现代码时应以对应实现仓库为准。WASI 文件系统提案当前处于Phase 3实现阶段见 docs/Proposals.md 的 Active Proposals 列表proposals/filesystem/README.md 同时给出了可移植性标准宿主实现必须在 Windows、macOS、Linux 上通过测试套件且至少要有两个完整独立的实现。六、设计权衡确定性、大小写语义与能力安全边界路径沙箱不是 WASI 文件系统的唯一安全决策理解这些权衡有助于把握沙箱的边界定位不完全确定性non-determinismWASI 文件系统不追求确定性语义。proposals/filesystem/README.md 解释得很清楚要确定性要么限制访问完全受控的私有文件系统与让用户访问现有文件系统的目标冲突要么要求实现大量额外工作去模拟特定行为与效率目标冲突。沙箱追求的是受限且不泄露而不是同一输入必然同一行为。大小写语义平台相关README 的设计讨论指出即使只在主流平台之间也存在大小写敏感与不敏感文件系统强制统一语义要么困难大小写折叠依赖 Unicode 版本细节各不相同要么不安全检查仅大小写不同的文件名时会与外部进程创建文件发生竞态。因此 WASI 选择按宿主平台行为走。优先兼容而非可移植types.wit的包级注释明确写道本接口prioritizes compatibility over portability——路径可能被折叠大小写或不会、并发删除可能失败、并发写入的持久性与原子性随平台而异。需要严格可移植语义的应用应改用键值存储或数据库。这些权衡与路径解析沙箱共同回答了同一个问题WASI 文件系统要可用、高效、不越权而不是处处一致、完全确定。沙箱负责把能力边界画死不能访问句柄之外的文件其余语义差异则交给平台与上层应用自行处理。七、总结一条从原理到实现的完整链路回顾全文WASI 文件系统路径沙箱的完整设计链路是设计源头借鉴 CloudABI 与 Capsicum 的能力安全模型proposals/filesystem/path-resolution.md并与 docs/DesignPrinciples.md 的无环境权限no ambient authorities原则一致——没有全局命名空间就没有可滥用的全局路径。API 形态所有路径函数只接受基础目录句柄 相对路径违规即返回error-code::not-permittedproposals/filesystem/wit/types.wit。核心算法手工解析时路径拆分为组件逐级openat(O_NOFOLLOW)遇符号链接用readlinkat展开并前插组件遇..弹出组件越出根即拒绝——这是不依赖内核扩展的通用实现。平台加速Linuxopenat2(RESOLVE_BENEATH)O_PATH/proc/self/fd、WindowsNtCreateFile、以及封装二者的 Rust 库cap-std在保持语义一致的前提下把逐级解析替换为内核级或高效实现。无论宿主采用哪种实现路径最终的安全承诺是一致的WASI 程序永远无法通过路径字符串访问到基础句柄所引用子文件系统之外的内容——即使面对外部进程并发创建的符号链接与目录变更也不例外。这既是本文所讲算法设计的出发点也是衡量任何 WASI 文件系统实现是否合格的基本标准。参考仓库文件索引便于深入研读核心文档proposals/filesystem/path-resolution.md接口类型定义WIT 源码proposals/filesystem/wit/types.wit、proposals/filesystem/wit/preopens.wit、proposals/filesystem/wit/world.wit接口 HTML 文档proposals/filesystem/imports.md提案概览与阶段proposals/filesystem/README.md、docs/Proposals.md设计原则与能力模型docs/DesignPrinciples.md、docs/Capabilities.md、docs/HighLevelGoals.md赞分享【免费下载链接】WASIWebAssembly System Interface项目地址https://gitcode.com/gh_mirrors/wa/WASI点击查看免费下载相关推荐Manim交互式开发深度解析实时动画制作与高效迭代技术Manim交互式开发深度解析实时动画制作与高效迭代技术 Manim作为3Blue1Brown开发的数学动画引擎其真正的强大之处不仅在于生成精美的数学可视化图形学音视频WASI filesystemWASI 0.3 文件系统 API基于 capability 的沙箱化文件访问设计解析WASI filesystemWASI 0.3 文件系统 API基于 capability 的沙箱化文件访问设计解析 导读 WASI filesystem终极指南在iOS设备上玩转Minecraft Java版PojavLauncher完整使用教程终极指南在iOS设备上玩转Minecraft Java版PojavLauncher完整使用教程 你是否曾梦想在iPhone或iPad上体验原汁原味的Mine游戏开发移动开发上一篇buildawesome 分页模板的组合拳自定义渲染 permalink 与 addAllPagesToCollections 在集合中的行为剖析下一篇SuperClaude Framework 集成 Serena MCP 服务器语义代码理解、项目记忆与跨会话持久化实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考