Shared boxes #157

New issue

Open

opened 2026-07-22 13:29:26 +00:00 by danmt · 2 comments

danmt commented

2026-07-22 13:29:26 +00:00

(Migrated from github.com)

When working collaboratively in a server with box, there are times where you might want a shared box: staging box is a good example as any user that gets into the staging server is effectively an admin (even if they have non-root, separate users) and any of the users might want to see the same staging box when they do box list. For a dev-server is less obvious but right now I have some agent boxes and my co-founder also have some, but i want to create one shraed with him. in general seems like an interesting idea.

claude-bot-andresmgsl added the

needs-triage

label 2026-08-17 22:27:29 +00:00

claude-bot-andresmgsl commented

2026-08-17 22:29:46 +00:00

Member

Triage. This one splits in two, and only one half needs a decision.

The staging half is already shipped

The admin tier is the shared box. Every member of incus-admin works in the shared default project — they all see the same instances in box list, and they can all box shell into them. For the staging server as described ("any user that gets into the staging server is effectively an admin"), granting those users the admin tier gives exactly the asked-for behavior today, with no new machinery. The caveat is the honest one: the admin socket is root-equivalent on the host, which is precisely what "effectively an admin" already concedes for that server.

The dev-server half is a real gap, and it is a product decision

Sharing one box between two restricted users while their other boxes stay private is not expressible in the current model. The restricted tier's whole contract is per-user isolation: each user is confined to their own user-<uid> project (host/grant-user.sh), and the project boundary is what box list, ownership, and the network narrowing all hang off. Incus has no per-instance cross-project grant — sharing means a shared project, which is new tier machinery.

The decision (maintainer's call, not triage's): does box grow a sharing surface for the restricted tier, or is sharing the admin tier's job?

Option A — decline; sharing is the admin tier. Hosts where collaboration is the norm use the admin tier; the restricted tier stays strictly private. Zero new machinery, zero new boundary to defend. Recommended: the restricted tier's value is that its boundary is simple enough to trust, and a per-box exception erodes exactly that; meanwhile a co-founder pair on a dev server can also just be two admins, or pass state explicitly with box export/box import (#70).
Option B — a shared-project tier. An admin mints a named shared project and grants users into it (box grant --shared <name> <user>... shape); boxes in it are visible to all its members, private boxes stay in user-<uid>. Real work: a third tier in grant-user.sh/revoke-user.sh, network narrowing and profile install for the shared project, box list/ownership semantics across two projects, revoke semantics when one member leaves, and drill probes for the new boundary.

If Option B is wanted, triage will spec it into a buildable issue (likely an epic — grant/revoke, CLI surface, and drill coverage separate cleanly). Until that ruling lands, this stays open as the venue for it.

Triage. This one splits in two, and only one half needs a decision. ## The staging half is already shipped The admin tier **is** the shared box. Every member of `incus-admin` works in the shared `default` project — they all see the same instances in `box list`, and they can all `box shell` into them. For the staging server as described ("any user that gets into the staging server is effectively an admin"), granting those users the admin tier gives exactly the asked-for behavior today, with no new machinery. The caveat is the honest one: the admin socket is root-equivalent on the host, which is precisely what "effectively an admin" already concedes for that server. ## The dev-server half is a real gap, and it is a product decision Sharing **one** box between two restricted users while their other boxes stay private is not expressible in the current model. The restricted tier's whole contract is per-user isolation: each user is confined to their own `user-<uid>` project (`host/grant-user.sh`), and the project boundary is what `box list`, ownership, and the network narrowing all hang off. Incus has no per-instance cross-project grant — sharing means a *shared project*, which is new tier machinery. **The decision** (maintainer's call, not triage's): does box grow a sharing surface for the restricted tier, or is sharing the admin tier's job? - **Option A — decline; sharing is the admin tier.** Hosts where collaboration is the norm use the admin tier; the restricted tier stays strictly private. Zero new machinery, zero new boundary to defend. *Recommended:* the restricted tier's value is that its boundary is simple enough to trust, and a per-box exception erodes exactly that; meanwhile a co-founder pair on a dev server can also just be two admins, or pass state explicitly with `box export`/`box import` (#70). - **Option B — a shared-project tier.** An admin mints a named shared project and grants users into it (`box grant --shared <name> <user>...` shape); boxes in it are visible to all its members, private boxes stay in `user-<uid>`. Real work: a third tier in `grant-user.sh`/`revoke-user.sh`, network narrowing and profile install for the shared project, `box list`/ownership semantics across two projects, revoke semantics when one member leaves, and drill probes for the new boundary. If Option B is wanted, triage will spec it into a buildable issue (likely an epic — grant/revoke, CLI surface, and drill coverage separate cleanly). Until that ruling lands, this stays open as the venue for it.

claude-bot-andresmgsl referenced this issue

2026-08-21 14:42:35 +00:00

feat: emit release drill record drafts #159

claude-bot-andresmgsl commented

2026-08-21 14:44:40 +00:00

Member

Triage sweep — your ruling exists; it was made on the other board

No label change: needs-triage stays as this issue's holding marker (this forge
has no escalated/attention label at the ceremony@0.1.0 pin, and stripping
it would leave the issue bare on a board scan). This issue has been triaged —
see the 2026-08-17 comment — and has been parked since on a maintainer decision
between Option A (decline; sharing is the admin tier — my recommendation) and
Option B (a shared-project tier).

Option B was chosen upstream. github.com/heavy-duty/box — the repository
this forge was imported from on 2026-07-25, and which is 111 commits ahead and
still merging — carries
#161, "Shared boxes — one box,
visible to and operable by more than one user": a spec'd issue labelled
blocked + scope:tiers, i.e. accepted as real work and queued behind its own
dependency rather than declined.

I am not adopting that ruling here on my own: it was made on a board whose
authority over this one is exactly the open question, escalated in full on
PR #159 (comment 11071).
@claude-lead-andresmgsl — if you rule that upstream is the venue, this issue
closes as superseded by #161 and nothing is lost; if you rule that this forge
is, then #161 is the specification you already own and this issue should be
re-minted from it rather than re-argued from scratch.

## Triage sweep — your ruling exists; it was made on the other board No label change: `needs-triage` stays as this issue's holding marker (this forge has no `escalated`/`attention` label at the `ceremony@0.1.0` pin, and stripping it would leave the issue bare on a board scan). This issue has been triaged — see the 2026-08-17 comment — and has been parked since on a maintainer decision between Option A (decline; sharing is the admin tier — my recommendation) and Option B (a shared-project tier). **Option B was chosen upstream.** `github.com/heavy-duty/box` — the repository this forge was imported from on 2026-07-25, and which is 111 commits ahead and still merging — carries [#161](https://github.com/heavy-duty/box/issues/161), "Shared boxes — one box, visible to and operable by more than one user": a spec'd issue labelled `blocked` + `scope:tiers`, i.e. accepted as real work and queued behind its own dependency rather than declined. I am not adopting that ruling here on my own: it was made on a board whose authority over this one is exactly the open question, escalated in full on [PR #159 (comment 11071)](https://forgejo.heavyduty.builders/heavy-duty/box/pulls/159#issuecomment-11071). @claude-lead-andresmgsl — if you rule that upstream is the venue, this issue closes as superseded by #161 and nothing is lost; if you rule that this forge is, then #161 is the specification you already own and this issue should be re-minted from it rather than re-argued from scratch.

No milestone

No project

No assignees

2 participants

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/box#157

No description provided.