Formalize host function implementations

[danbugs]

Summary

The current host function implementations in lib.rs (filesystem sandbox, networking, tool dispatch) work but were built incrementally. Formalize them with a clearer structure, and consider extracting shared functionality into a reusable library.

cap-std and James's cap_fs.rs

cap-std (Bytecode Alliance) provides capability-based filesystem access — Dir handles that prevent path traversal by construction, no manual .. / symlink checking needed. The wrapper in hyperlight-sandbox/cap_fs.rs builds on this with:

• Preopened directories with explicit FilePerms / DirPerms bitflags
• Stream-based read/write (not just one-shot)
• Directory listing (create_dir_stream / read_dir_entry) — which is a known limitation in our current FsSandbox
• Clean separation of read-only input dirs and writable ephemeral output dirs

Shared library opportunity

Three projects currently implement sandboxed filesystem host functions independently:

1. hyperlight-unikraft — FsSandbox in lib.rs (manual path resolution + canonicalize checks)
2. hyperlight-sandbox — CapFs in cap_fs.rs (cap-std based, more complete)
3. hl-js — also does filesystem stuff

Extracting a shared hyperlight-host-fs (or similar) crate based on cap-std would:

• Eliminate duplicated path-traversal defense code across projects
• Give all projects directory listing for free
• Centralize the security-critical code for auditing
• Let each project just register dispatch handlers that delegate to the shared crate

Design questions

• Should the shared crate also cover networking (NetworkPolicy, socket proxy) or just filesystem?
• Define a trait or interface pattern for host function handlers
• Standardize the JSON-RPC schema for each function (request/response types)
• Make it easy to add new host functions without touching a monolithic registration block