connect-only members cannot open a team vault, and the client calls it "Access revoked"

[kipavy]

Found while live-testing #70 (PR #186) with two real accounts against an isolated server.

What happens

A member holding only the built-in connect-only role opens the team vault they were just invited to and sees:

Access revoked — You no longer have access to this team vault. Contact the team owner.

They were never revoked. They are in team_members, a key-holder has wrapped the vault key for them, and the row exists in team_vault_keys.

Why

GET /v1/teams/:team_id/vault-key (server/src/routes/team_sync.rs) requires PERM_VIEW_SECRETS:

crate::permissions::require_all_team_permissions(
    &pool, team_id, auth.0,
    &[crate::permissions::PERM_VIEW_SECRETS],
).await?;

connect-only is 28676 in BUILTIN_ROLES = CONNECT | START_TERMINAL_SESSION | JOIN_TERMINAL_SESSION | VIEW_TERMINAL_SESSIONS. No VIEW_SECRETS, so the route returns 403, and getTeamVaultKey (src/services/teamVaultSync.ts:119) maps 403 to "forbidden" — the revocation state. From the client's side a role denial and a revocation are indistinguishable.

Note the asymmetry: reconcileTeamVaultKeys happily wraps and uploads a key for a connect-only member (put_vault_keys only validates team membership), so the server stores a key that the same server then refuses to hand back.

When it bites

Exactly at first access. fetchTeamData tries listTeamObjects first; once the vault holds objects that path serves them and the vault opens for a connect-only member anyway. It is the empty team vault — the one a joiner meets right after the owner converts a private vault and invites them — that falls through to the key route and 403s.

So the very first thing a connect-only invitee sees is a false revocation notice, and the "land them on the connections they can use" behaviour from #70 has nothing to land on.

Reproduction

1. Owner A converts a private vault into a team vault (no hosts pushed yet).
2. A invites B with initial role connect-only only.
3. B accepts, A comes online so the key is wrapped (Vault keys upserted key_count=2).
4. B selects the vault → "Access revoked". Server log: GET .../vault-key → 403.
5. A adds one host to the team vault → B reloads → the vault opens normally.

The decision this needs

Should a connect-only member hold a wrapped vault key at all?

• Yes — they need the vault contents to connect to anything, and they already receive one in practice. Then get_my_vault_key should gate on PERM_CONNECT || PERM_VIEW_SECRETS rather than VIEW_SECRETS alone, and the credential-hiding stays where it already is (team_vault_secrets / the VIEW_SECRETS checks on the secret payloads).
• No — then reconcileTeamVaultKeys should stop wrapping keys for members who may never fetch them, and the client needs a real state for "your role cannot unlock this vault" instead of borrowing the revocation copy.

Either way the client should stop rendering a bare 403 as "Access revoked" when the user is still a listed member. No copy was invented for it in PR #186 because the answer changes what the copy should say.

Related: #70, #41, #68.

[kipavy]

Fixed by #191 (client, dev@c00143ab) and VoltiusApp/server#11 (main@1b284f2, deployed to production 2026-08-26).

The premise in the original report turned out to be wrong in a useful way: a connect-only member does not need the vault key to see the vault. list_objects is membership-gated and returns plaintext metadata, so a populated team vault opens for them today. Only the empty vault falls through to GET /vault-key and 403s — which is exactly the vault a joiner meets.

So neither of the two options in the issue was taken. get_my_vault_key was left at PERM_VIEW_SECRETS: widening it buys nothing for hosts, and would have been unsafe anyway — GET /sync-blob was membership-only while its writer required six permissions, so key + blob together would have handed a connect-only member every secret in the vault. Server#11 closed that read gate first.

The client now separates the two meanings of a 403 the way the routes cannot: still in your own team list means role restriction, and the empty object list is shown as what it is. Not in it means revoked, unchanged.

Not fixed here, and the real reason the role is unusable: #190 — a connect-only member can never fetch credential ciphertext nor the key to decrypt it, so they cannot connect to any host with a stored password or key passphrase.