Permissions
Grants cover whole filesystems
A grant gives a member, a group, or an API key access to one whole
filesystem, read-only (ro) or read-write (rw). rw implies ro. To
separate what different people or agents can see, give them different
filesystems: there are no per-directory grants.
Roles
| Role | Can |
|---|---|
| owner | everything an admin can, plus managing owners and deleting the organisation |
| admin | manage filesystems, grants, members, groups, and keys; mount every filesystem read-write |
| member | mount what they or their groups are granted |
API keys
An API key belongs to one organisation and never holds more than the member who created it. A key may:
- list, read and see the usage of the filesystems it has a grant on;
- create a filesystem in its organisation, which gives the key a read-write grant on it, while its creator is still an owner or admin. The card requirement and quotas apply as for people;
- create mount sessions up to its grant, and list or revoke the sessions it created.
Deleting filesystems, changing grants, and managing members, groups,
invitations, keys, billing or the organisation are for people only: a key
gets 403 with code api_key_forbidden. GET /api/v1/me shows a key's
organisation as api_key: {id, org_id}.
Mode is chosen per session
Each mount session picks ro or rw, up to the grant. You can mount
read-write on your Linux laptop while an agent's sandbox mounts the same
filesystem read-only.
What revokes sessions
Every change that reduces privileges revokes the affected sessions and unused tickets at once: deleting or downgrading a grant, removing someone from a group that carried the grant, removing a member, revoking or expiring an API key, and deleting the filesystem. No new operation is admitted more than 15 seconds later; the client creates a new session under the new authority.
File modes are presentation
POSIX owners and mode bits inside a mount are shown for tools that expect them. They are not an access-control boundary; grants are.