Skip to content

(feat) early snap support#1238

Draft
zyga wants to merge 3 commits intoNVIDIA:mainfrom
zyga:feature/upstream-snap
Draft

(feat) early snap support#1238
zyga wants to merge 3 commits intoNVIDIA:mainfrom
zyga:feature/upstream-snap

Conversation

@zyga
Copy link
Copy Markdown

@zyga zyga commented May 7, 2026

Summary

This pull request adds early support for snap packaging so that openshell can be built in CI and eventually distributed from the snap store.

Related Issue

Changes

  • modify the VM driver to account for the snap sandbox limiting access to arbitrary chown to user/group 10001 - instead use the special snap_daemon user that is allowed by the sandbox
  • change the unpacked rootfs so that /sandbox in the rootfs is owned by that new snapd_daemon user UID/GID while still being called sandbox in the vm
  • add mise tasks and scaffolding for snap packaging without invoking all of snapcraft yet (that is coming as a follow-up).

Testing

  • mise run pre-commit passes
  • Unit tests added/updated
  • E2E tests added/updated (if applicable)

Checklist

  • Follows Conventional Commits
  • Commits are signed off (DCO)
  • Architecture docs updated (if applicable)

zyga and others added 3 commits May 7, 2026 18:16
The OpenShell snap cannot chown VM rootfs files to the default 10001:10001
sandbox identity because snap confinement only permits ownership changes to
the snap_daemon shared user and group.

Add SNAP_SANDBOX mode for the VM driver so snap builds map the in-VM
sandbox user and group to 584788:584788, rewrite existing /etc/passwd and
/etc/group sandbox entries, normalize /sandbox ownership after extraction,
and salt the prepared rootfs cache by the effective sandbox UID/GID.

Skip symlinks during /sandbox ownership normalization so the snap-sandboxed
gateway does not need CAP_DAC_OVERRIDE for symlink ownership changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This is a stepping stone towards a full snapcraft based build, by allowing
us to reuse the existing mise-based build-system to construct the binaries
and merely assemble the snap with "snap pack".

When building the package and installing locally please connect both kvm,
system-observe and ssh-public-keys (this grants access to connecting over
ssh).

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Document how to build and use a locally-built snap package of openshell, as
well as how it works internally.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented May 7, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 7, 2026

Thank you for your submission! We ask that you sign our Developer Certificate of Origin before we can accept your contribution. You can sign the DCO by adding a comment below using this text:


I have read the DCO document and I hereby sign the DCO.


You can retrigger this bot by commenting recheck in this Pull Request. Posted by the DCO Assistant Lite bot.

@alexclewontin
Copy link
Copy Markdown

I will put another set of eyes on this from a snapping perspective

@zyga
Copy link
Copy Markdown
Author

zyga commented May 7, 2026

With this I can get a working VM sandbox on Ubuntu 26.04. My next steps are to propose a full snapcraft.yaml and then a full publishing pipeline.

@zyga
Copy link
Copy Markdown
Author

zyga commented May 7, 2026

I have read the DCO document and I hereby sign the DCO.

@zyga
Copy link
Copy Markdown
Author

zyga commented May 7, 2026

recheck

@zyga zyga changed the title Feature/upstream snap (feat) early snap support May 7, 2026
path = "src/main.rs"

[features]
SNAP_SANDBOX = []
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cargo feature names would normally be lowercase, so snap_sandbox or snap-sandbox.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack, I'll update this in the next round

fs::symlink_metadata(&link)
.expect("stat symlink")
.file_type()
.is_symlink()
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is checking that the symlink is still a symlink. I imagine we want to validate the owner/group of the file that the symlink references, to make sure the chown did not affect it?

let mut lines = Vec::new();
for existing in contents.lines() {
if exists(existing) {
if !replaced {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this is going out of our way to only replace the first matching line. If there's not a specific reason for doing this, it could be simpler to just replace all matching lines. Alternatively, if we're only expecting a single match, we could give an error if a second match is found. I think this function is only used to search for a specific user or group in passwd, group, shadow, and gshadow, in which case it would be a misconfiguration for the same user or group to appear twice in the same file?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants