A host=no box with an incus group still hands out the bare socket #58

New issue

Closed

opened 2026-07-19 17:24:32 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-19 17:24:32 +00:00

(Migrated from github.com)

A `host=no` box with an `incus` group still hands out the bare socket

Found by claude-bot-andresmgsl reviewing #53, and reproduced there in a
mount-namespace run.

The gap

commands/users-apply.sh:212 on main gates the box role on the group's
existence alone:

case ",$roles," in *,box,*) if [ "$INCUS_OK" -eq 1 ]; then want="$want incus"; fi ;; esac

The host= trait decides what an absent incus group means — die on
host=yes, skip-with-warning on host=no. But when the group is present
the trait is not consulted at all. So on a host=no (or marker-less) box
where incus nonetheless exists, box-role users get a bare usermod -aG incus with no tier behind it.

That is the half-grant state: the socket without the project. #49 calls it
worse than not granting at all, because incus-user will lazily create an
unhardened project for whoever opens that socket — incusbr-<uid>, NAT
on v4 and v6, no ACL, no dns.mode=none, no port isolation.

How you get there

A marker/reality mismatch. box setup-host ran on the machine — leaving the
group — but the box's /etc/rig/role says host=no, e.g. because
rig bootstrap was given --host no, or the machine was repurposed and
re-bootstrapped with different traits.

Reproduced during #53's review: flipping the marker to host=no handed a
test user the bare socket that the host=yes path had correctly withheld
when their grant failed.

The decision this needs

Two coherent answers, and the repo should pick one deliberately:

The marker wins. host=no means this box does not host VMs, so the
box role is skipped regardless of what groups happen to exist. Simple,
and consistent with the trait being the box's declared identity. Costs:
a genuine VM host mislabelled host=no silently stops provisioning.
Reality wins, loudly. The group's presence is evidence the machine
really does host VMs, so converge — but warn that the marker disagrees
and name rig bootstrap as the fix. Costs: acting on a trait the box
does not claim.

Either beats today's behavior, which takes the trait seriously only when
the group is missing.

Context

Pre-existing on main, unchanged by #53 — that PR deliberately scoped
itself to the host=yes path. Raised at review as non-blocking.

# A `host=no` box with an `incus` group still hands out the bare socket Found by `claude-bot-andresmgsl` reviewing #53, and reproduced there in a mount-namespace run. ## The gap `commands/users-apply.sh:212` on `main` gates the `box` role on the *group's existence* alone: ```sh case ",$roles," in *,box,*) if [ "$INCUS_OK" -eq 1 ]; then want="$want incus"; fi ;; esac ``` The `host=` trait decides what an **absent** `incus` group means — die on `host=yes`, skip-with-warning on `host=no`. But when the group is **present** the trait is not consulted at all. So on a `host=no` (or marker-less) box where `incus` nonetheless exists, box-role users get a bare `usermod -aG incus` with no tier behind it. That is the half-grant state: the socket without the project. #49 calls it worse than not granting at all, because incus-user will lazily create an **unhardened** project for whoever opens that socket — `incusbr-<uid>`, NAT on v4 *and* v6, no ACL, no `dns.mode=none`, no port isolation. ## How you get there A marker/reality mismatch. `box setup-host` ran on the machine — leaving the group — but the box's `/etc/rig/role` says `host=no`, e.g. because `rig bootstrap` was given `--host no`, or the machine was repurposed and re-bootstrapped with different traits. Reproduced during #53's review: flipping the marker to `host=no` handed a test user the bare socket that the `host=yes` path had correctly withheld when their grant failed. ## The decision this needs Two coherent answers, and the repo should pick one deliberately: 1. **The marker wins.** `host=no` means this box does not host VMs, so the `box` role is skipped regardless of what groups happen to exist. Simple, and consistent with the trait being the box's declared identity. Costs: a genuine VM host mislabelled `host=no` silently stops provisioning. 2. **Reality wins, loudly.** The group's presence is evidence the machine really does host VMs, so converge — but warn that the marker disagrees and name `rig bootstrap` as the fix. Costs: acting on a trait the box does not claim. Either beats today's behavior, which takes the trait seriously only when the group is missing. ## Context Pre-existing on `main`, unchanged by #53 — that PR deliberately scoped itself to the `host=yes` path. Raised at review as non-blocking.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/rig#58

No description provided.