在容器與虛擬化技術風行的今天，RustBox 是一個簡潔的專案：不是去競爭 Docker 或 Kubernetes 的功能豐富，而是回歸核心，從最底層的 Linux kernel 機制（namespaces、cgroups、OverlayFS 等）構建一個最簡潔的「Sandbox／隔離運行環境」。

這篇文章會帶你從動機、架構、實作細節到限制與未來可能方向，一步步拆開這個專案，幫助你快速理解其設計與挑戰。

一、為什麼要有這樣的工具？動機與定位

在現代軟體與安全場景中，有不少情境會需要「隔離執行不可信程式碼」：

• 沙箱環境 (sandbox) 測試 plugin、macro、script
• 學習 / 教育用途：理解 Linux namespace、cgroups、文件系統隔離 etc.
• 比起將整個容器引擎包進來，只要一個簡單隔離機制就好

RustBox 的定位，就是在這種「想理解底層、想要輕量、想要可控」的場景下，提供一個比起完整容器系統更精簡、更直接對底層機制操作的選擇。

RustBox 結合了下列幾個 Linux 機制來實現隔離：

• OverlayFS：用來構建一個可寫的「覆寫層」在底層只讀基礎檔案系統之上
• cgroups v2：用來限制記憶體、CPU 等資源
• Linux namespaces：如 PID、IPC、NET、USER、UTS 等命名空間隔離
• Double fork：確保在子進程退出後，各種掛載 (mount)、命名空間、cgroup 等可以正確卸載與清理

二、整體架構 / 流程

下面是一個簡化的流程／架構圖與說明：

[Outer Parent Process]
    └─> fork() #1
        ├─> [Namespaced Parent Process]
        │   ├─> unshare() - Creates new namespaces
        │   └─> fork() #2
        │       ├─> [Inner Child Process]
        │       │   ├─> Mount /proc and /dev
        │       │   ├─> chroot() to merged overlay
        │       │   ├─> chdir() to working directory
        │       │   └─> execv() - Execute shell/binary
        │       └─> [Namespaced Parent] waits for inner child
        │           └─> Unmounts /proc and /dev inside namespace
        └─> [Outer Parent] waits for namespaced parent
            ├─> Unmounts overlay filesystem
            └─> Cleans up cgroups

上面流程中有幾個關鍵點：

三、細節拆解：OverlayFS / cgroups / namespace

下面我們把幾個關鍵模組拆出來看，在實作上比較值得注意的地方：

1. OverlayFS 的使用

• OverlayFS 是 Linux 提供的一種 union filesystem，可以讓你把底層一層只讀 (lower) + 一層可寫 (upper)，最後再透過 merge (workdir) 融合成一個可寫可讀的視圖。
• RustBox 會在使用者給定的 base_dir 裡面建立一個 overlay 結構（lower、upper、work、merged）作為該沙箱進程的檔案系統鏡像。
• 程序在 chroot 到這個 merged 目錄後，就以這裡為根目錄運行。
• 當沙箱程式退出後，RustBox 要負責卸載 (umount) merged、cleanup upper/work 等目錄。

實作中需注意的點包括：掛載選項權限、掛載失敗要回滾、不同 namespace 下的掛載可見性、錯誤處理與資源釋放。

2. cgroups v2 的資源限制

• RustBox 支持設定記憶體限額 (memory_limit) 和 CPU 限額 (cpu_limit)
• 它會在 /sys/fs/cgroup (或指定 cgroup 根目錄) 下建立一個子 cgroup，把要執行的進程加入其中
• 這樣進程在執行期間就受到記憶體與 CPU 的限制
• 在程序退出時，Outer Parent 還要刪除該 cgroup

要處理的挑戰有：v2 cgroup 的 subsystem 管理、子 cgroup 權限、刪除時的 race condition、子進程退出但 cgroup 尚未完全清除（waiting for tasks 完成）等。

3. Linux Namespaces

RustBox 用到的 namespace 類型包括：

• PID namespace：讓子進程在新的 PID namespace 中，以 1 作為 root
• UTS namespace：隔離 hostname / domain name
• NET namespace：隔離網絡（通常沙箱內無網絡或可自訂網絡）
• IPC namespace：隔離 IPC 資源
• USER namespace：可選，用來控制 UID / GID map
• 其他 namespace 如 mount namespace 內部掛載點隔離

實作時要用 unshare、clone、mount（在 namespace 內）等系統呼叫。要注意 namespace 關係與掛載點可見性的問題。

四、使用方式與配置範例

RustBox 提供一個簡單的 CLI 介面來啟動沙箱程式：

# 用預設設定啟動
sudo ./target/debug/rustbox

# 自訂參數
sudo ./target/debug/rustbox \
  --base-dir ./rootfs \
  --memory 256M \
  --cpu-limit 0.5 \
  --shell /bin/bash \
  --workdir /root

其對應的配置結構為：

pub struct SandboxConfig {
    pub base_dir: String,      // OverlayFS 所在根目錄（如 ./rootfs）
    pub memory_limit: String,  // 記憶體上限（如 "100M", "1G"）
    pub cpu_limit: String,     // CPU 限額（如 "0.5" 表示半個核心）
    pub shell_path: String,    // 要執行的 shell 或 binary 路徑
    pub workdir: String,       // 啟動後的工作目錄（如 "/"、"/root"）
}

使用者可以客製這些參數來控制 Sandbox 行為。(GitHub)

五、限制、風險與待改進方向

儘管 RustBox 輕量工具，但它在實務應用上還有一些限制與風險值得注意：

1. 需要 root 權限
   因為要掛載檔案系統、建立 namespace、操作 cgroup 等，RustBox 通常需要 root 權限執行。這在某些環境中是不可接受的。

2. 功能完整性不如容器引擎
   RustBox 沒有像 Docker 那樣複雜的網路設定 (bridge, port mapping)、卷 (volume)、鏡像管理、日誌、生命週期管理等功能。
   它的目標不是代替 Docker，而是作為更底層的工具或教學平台。

3. 資源清理的競爭條件 / 程式錯誤風險
   在多進程、異常退出、錯誤路徑等情況下，要保證 overlay、掛載點、cgroup 等都能正確清理，是很具挑戰性的。

4. 可靠性與穩定性
   在極端負載或複雜情況下可能會出錯（掛載失敗、子進程殘留、cgroup 刪除失敗等）。

5. 跨平台限制
   RustBox 僅適用於支援 overlayfs、cgroup v2 的 Linux 系統，不支援 Windows、macOS 等。

6. 安全性考量
   這類沙箱如果有漏洞（掛載逃逸、namespace 泄漏、特權提升等），可能存在被攻破的風險。需要非常謹慎在安全場景中使用。

六、心得與應用建議

通過閱讀和實作 RustBox，我得到的體會與給未來使用者／開發者的建議包括：

• 如果你對 Linux kernel namespace、cgroup、檔案系統隔離等底層機制有興趣，RustBox 是一個範例。
• 可做為基底延伸：你可以從這個基礎上擴展網路功能、卷掛載、日誌管控、監控接口、鏡像管理等。
• 小心清理與錯誤處理：在實際改寫／延伸時，錯誤路徑與資源釋放要非常嚴謹，避免殘留掛載點或 cgroup。
• 可用於 sandbox testing：在某些場景中，用這樣的 sandbox 來執行插件、script、untrusted 程式，比起直接 fork + seccomp 等手段，提供更高隔離度。
• 不要當作全面替代容器：如果你需要複雜網路、分布式調度、影像上下傳、監控、生態系整合等，RustBox 並不會比 Docker / containerd / Podman 好。