bytecodealliance / bytecodealliance/cap-std

Ability to construct virtual `Dir`s to mount files and subdirectories into

未关闭
#352 5 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Rust
星标
821
派生
57
平均合并
1 小时 16 分钟
30 天内合并 PR
4

描述

Specifically with the option for those files/dirs to just be paths that don’t need to be opened when mounted. Note: When I say “mount” here this would only be internal to the `Dir` struct and not actual mounts on the underling filesystem. Similar to `Pool`’s `insert` methods.

Would particularly be interesting to create a root `Dir` which would just be `/` on Unix but on Windows a folder exposing all drive letters as subfolders. I understand that this specific use case may be controversial, as it seems to go against the spirit of this crate. But I believe the opposite to be true: The great thing about this API is that it doesn’t just have one or two layers (as more basic security systems), but arbitrarily many as each `Dir` recursively can be used to create narrower views. So I don’t think one global directory as the base to craft more specialised capabilities would inherently be a bad idea.

Based originally on thinking in https://github.com/bytecodealliance/wasmtime/issues/8552 to solve the problem of Windows (unlike Unix) not having a single root folder but essentially one for each volume, which makes `cap-std` difficult to use in some contexts.

I apologise should what I propose already be possible, in a quick look into the docs I haven’t figured out a way to do this.

贡献指南

打开贡献指南

调研方向

首先阅读现有的 Dir 构造 API 和 Pool 的 insert 方法,然后比较路径的打开和表示方式。确定是否可以在不打开虚拟文件和子目录的情况下挂载它们,同时保留递归能力限制。Done 应包括一个已确定的跨平台设计,包括提议的 Windows 驱动器根目录用例,以及有文档记录的行为和测试。

由索引模型根据 Issue 内容生成。

评估

技术栈
rust
领域
operating-systems, security
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。