users apply revokes the incus group behind box revoke's back #50

New issue

Closed

opened 2026-07-19 16:05:10 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-19 16:05:10 +00:00

(Migrated from github.com)

`users apply` revokes the incus group behind `box revoke`'s back

The bug

users apply converges membership in rig-admin rig incus exactly —
added and removed to match the file. For incus, the removal is a bare
gpasswd -d (commands/users-apply.sh:223, and again at :285 for the
dropped/renamed-user sweep):

gpasswd -d "$u" "$g" >/dev/null
log "removed $u from $g"

For rig-admin and rig that is the whole story — rig owns those groups.
For incus it is not: box owns that group, and box revoke
(box/host/revoke-user.sh) does strictly more with it.

What apply silently skips

box revoke removes the group and then says what the group removal does
not do:

WARNING: <user> has live sessions, and group membership is read at login —
         those sessions keep the socket until they end. To end them now:
         sudo loginctl terminate-user <user>

Supplementary groups are fixed at login. Dropping a user from the group
database does nothing to a session they already hold — a leftover tmux keeps
the Incus socket until it dies. box revoke treats that as load-bearing
enough to warn about by name and hand over the remedy.

rig users apply logs removed <user> from incus and moves on. An operator
who removes someone from the users file, watches apply report success, and
believes their VM access is gone is wrong for as long as that user holds a
session — and nothing in the output suggests otherwise.

This is independent of the grant gap: it is wrong today, on every apply that
drops a box-role user.

Why it is worse than it looks

box revoke's own comments flag the sharper edge: a stale-group process can
touch incus-user after a revoke and lazily recreate the project with
incus-user's stock defaults — the unhardened NAT bridge, un-narrowed. That
is why --purge terminates sessions first. A bare revoke accepts the risk
and says so out loud. rig's silent gpasswd -d accepts the same risk and
says nothing.

Options

Call box revoke when dropping the box role on host=yes — the
symmetric counterpart to the grant issue, and the option that keeps one
owner for the group. Never --purge from apply: deleting someone's
running boxes is not a convergence step and must stay an explicit
admin act.
Keep gpasswd -d, add the warning. Cheaper, no new box dependency on
the revoke path, but it duplicates box's knowledge in rig and will drift.

Option 1 preferred, for the same reason as the grant issue: box owns the
group, so box should be the one to give and take it.

Note

Apply must still handle a user dropped from the file on a host=no box, or
on a host where box is not installed — the group is absent there and there is
nothing to revoke. The existing INCUS_OK guard covers the read side; the
removal path at :223 and :285 currently has no equivalent.

# `users apply` revokes the incus group behind `box revoke`'s back ## The bug `users apply` converges membership in `rig-admin rig incus` **exactly** — added and removed to match the file. For `incus`, the removal is a bare `gpasswd -d` (`commands/users-apply.sh:223`, and again at `:285` for the dropped/renamed-user sweep): ```sh gpasswd -d "$u" "$g" >/dev/null log "removed $u from $g" ``` For `rig-admin` and `rig` that is the whole story — rig owns those groups. For `incus` it is not: box owns that group, and `box revoke` (`box/host/revoke-user.sh`) does strictly more with it. ## What apply silently skips `box revoke` removes the group and then says what the group removal does *not* do: > ``` > WARNING: <user> has live sessions, and group membership is read at login — > those sessions keep the socket until they end. To end them now: > sudo loginctl terminate-user <user> > ``` Supplementary groups are fixed at login. Dropping a user from the group database does nothing to a session they already hold — a leftover tmux keeps the Incus socket until it dies. `box revoke` treats that as load-bearing enough to warn about by name and hand over the remedy. `rig users apply` logs `removed <user> from incus` and moves on. An operator who removes someone from the users file, watches apply report success, and believes their VM access is gone is **wrong for as long as that user holds a session** — and nothing in the output suggests otherwise. This is independent of the grant gap: it is wrong today, on every apply that drops a box-role user. ## Why it is worse than it looks `box revoke`'s own comments flag the sharper edge: a stale-group process can touch incus-user *after* a revoke and lazily recreate the project with incus-user's stock defaults — the unhardened NAT bridge, un-narrowed. That is why `--purge` terminates sessions first. A bare revoke accepts the risk and says so out loud. rig's silent `gpasswd -d` accepts the same risk and says nothing. ## Options 1. **Call `box revoke` when dropping the `box` role on `host=yes`** — the symmetric counterpart to the grant issue, and the option that keeps one owner for the group. Never `--purge` from apply: deleting someone's running boxes is not a convergence step and must stay an explicit admin act. 2. **Keep `gpasswd -d`, add the warning.** Cheaper, no new box dependency on the revoke path, but it duplicates box's knowledge in rig and will drift. Option 1 preferred, for the same reason as the grant issue: box owns the group, so box should be the one to give and take it. ## Note Apply must still handle a user dropped from the file on a `host=no` box, or on a host where box is not installed — the group is absent there and there is nothing to revoke. The existing `INCUS_OK` guard covers the read side; the removal path at `:223` and `:285` currently has no equivalent.

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#50

No description provided.