Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

nvx-rs: GPT images, the RAM upper and protected paths in `nvx-rs sandbox`

Open
  • Is something wrong?
#818 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
infrastructure

Research direction

Start with host/cli/sandbox/mod.rs and trace how run, provision and start build the typed plan and PreparedLaunch; then read the referenced issues #813 and #817 for GPT bindings and tmpfs initialization. The work spans format and upper planning, binding records, path protection across canonical paths and aliases, and acceptance tests across three hypervisors. Done means all four combinations work, changed GPT bindings and protected shares are rejected as specified, and unchanged goldens pass.

Written by the indexing model from the issue text.

Description

Parent: #816. Needs: #817, whose init boots a GPT distro and the tmpfs upper. Builds on #813's GPT bindings. Delivers, with #817 and #591's docs: #558.

Goal. nvx-rs sandbox run, provision and start accept every format and upper that the shared plan supports, and refuse a share that reaches the sandbox's own files.

Today (dev c5a0dd7):

  • --layer ROLE,PATH,EROFS_UUID names an EROFS distro only, and the CLI plans it over an ext4 scratch (host/cli/sandbox/mod.rs). The library's GPT bindings (#813) are unused by the CLI.
  • run and provision verify the layer when a manifest sits beside it. provision records its binding, and start checks it without reading the layer again; both launch through PreparedLaunch (#653, #752).
  • The CLI refuses overlapping host paths among a sandbox's own shares, but not a share that reaches its state directory, scratch, layers or bundle.

Scope:

  1. Formats and uppers: a GPT distro named by its disk GUID, and the tmpfs upper, with exactly one nvx_overlay_upper=ramfs token and no scratch block or token. They are planned through the typed plan for sandbox run, provision and start. The option forms are settled in the PR; today's EROFS forms keep their meaning.
  2. Bindings: provision records a GPT binding (#813) as it records an EROFS one, and start checks it by metadata only. A tmpfs sandbox records and claims no scratch.
  3. Protected paths: a share is refused if its host path equals, contains or lies inside the sandbox's state directory, scratch, layers or bundle. Paths are compared by canonical path and by identity, at provision and again at start; sandbox run, which has no state directory, checks the rest.
  4. Records: the sandbox's records name its format and upper.

Not in scope: guest root assembly (#817); nvx-rs run's shares (#802); protected roots chosen by the library; image management.

Acceptance:

  • sandbox run, provision and start each boot all four format and upper combinations on KVM, MSHV and WHP. Tests assert the selected filesystem and upper, the expected identities, the block size, and no scratch in RAM mode.
  • A GPT image that changed after provision fails start without reading content, and a wrong disk GUID fails the assembly. Conflicting upper settings are refused.
  • Protected-path tests cover a single share, symbolic link, junction and bind-mount aliases, and a state directory created during provision.
  • Unchanged cases keep their goldens. Intended changes are limited to the format token, the protected paths and the records.

Carries over: #622's scope 7 (A4 PR 7), apart from the binding that provision already records, and the CLI's part of #622's first acceptance item.

Dominant language
Rust
Stars
758
Forks
48
Avg merge
16h 56m
Merged PRs (30d)
363

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.