Permissions reference

This is the complete catalogue of what you can grant. Everything Everlock controls is reachable through one grant model: a role attached to a subject (user or group) on an access path. There is no separate per-service permission system — the same three roles and the same path syntax apply to Git, mail, sites, DNS, registries, calendars, and everything else.

If you have only seen the examples on the Git access and Groups pages, this page is the full picture: every backend, every path it understands, every namespace and sub-resource it recognises, and exactly what reader, writer, and owner mean for each one.

The model in one paragraph

A grant is <subject> <path> <role>. The path has exactly three /-separated segments — frontend / backend / namespace. Any segment may be * to match all values. The role is one of three ordered levels — reader < writer < owner — and a higher role always implies the lower ones. A request is allowed when the actor (or one of their groups) holds a grant whose path matches the request path and whose role meets the capability the backend asked for. Effective access is the union of all matching grants; there is no deny rule.

/users grant  <login> <path> <role>
/groups grant <group> <path> <role>
/users revoke <login> <path>
/groups revoke <group> <path>
/users grants <login>            # inspect

See Managing users and Groups for the lifecycle commands. This page is about what the <path> and <role> can be.

The three roles

Role	Read	Write	Delete	Ordering
`reader`	yes	no	no	lowest
`writer`	yes	yes	no	implies `reader`
`owner`	yes	yes	yes	implies `writer`

These map onto the capability checks every backend performs: can_read (satisfied by any role), can_write (writer or owner), and can_delete (owner only). What "read", "write", and "delete" mean is defined by each backend — the tables below spell it out per backend.

Aliases are accepted when granting: read/r, write/w, own/o.

The path segments

frontend / backend / namespace

Segment	What it is	Known values
`frontend`	the protocol the request arrives on	`ssh`, `http`, `smtp`, `imap`, `*`
`backend`	the backend family	`git`, `mail`, `site`, `oci`, `image`, `calendar`, `contacts`, `dns`, `ai`, `*`
`namespace`	the specific resource within that backend	a repo name, a registry name, a zone, a `domain:mailbox`, … or `*`

The frontend segment is not just cosmetic. For most backends a resource is reachable on exactly one protocol, so */git/<repo> and ssh/git/<repo> are equivalent in practice and * is the convenient, future-proof choice. But for mail the frontend segment is load-bearing: imap governs reading a mailbox and smtp governs sending as it, so the segment you choose decides which capability you hand out. See Mail below.

Backend reference

The table below is the quick index; each backend has a section underneath with the exact namespace rules and role meanings.

Backend	Frontend(s)	Path pattern	Namespace is	Sub-resources	`reader`	`writer`	`owner`
Git	`ssh` (→ `*`)	`*/git/<repo>[:pulls]`	repository name, optionally its PR namespace	yes — `:pulls`	clone / fetch	push	delete refs, manage repo
Mail	`imap`, `smtp`	`<fe>/mail/<domain>[:<mailbox>]`	domain, optionally a mailbox	yes — `:mailbox`	read mailbox (IMAP)	send as mailbox (SMTP)	read + send
Site	`http`	`http/site/<name>`	site name	no	view the site	(no extra serving right)	(no extra serving right)
OCI	`http`	`http/oci/<registry>`	registry name	no	pull	push	delete tags/manifests
Image	`http`	`http/image/<instance>`	instance name	no	access (guest)	—	admin of the instance
Calendar	`http`	`http/calendar/<instance>`	calendar instance	no	read (GET/PROPFIND/REPORT)	modify (PUT/DELETE/MKCOL)	modify
Contacts	`http`	`http/contacts/<instance>`	address-book instance	no	read	modify	modify
Files	`http`	`http/files/<share>`	share name	no	browse and download	upload, rename, delete, lock	upload, rename, delete, lock
DNS	`ssh` (admin)	`ssh/dns/<zone>`	zone apex	no	view records	add/update records	delete the zone
AI	`ssh`	`ssh/ai/default`	fixed (`default`)	no	—	use AI prompting	use AI prompting
Vault	`http`	`http/vault/<instance>`	vault instance	no	—	—	manage the instance's accounts
System admin	`*`	`//*`	everything	—	—	—	full administration

Backends not in this table — OAuth token issuance and the admin HTTP interface — do not define their own grantable paths. OAuth authenticates the end user and then mints tokens; it adds no */oauth/* path you grant against.

The vault (backend-vault-http) separates three questions that the other backends answer in one place. Its request path is the deliberate exception to the shared model: Bitwarden clients authenticate with the account's own master-password and token flow, so Everlock bypasses its HTTP auth for the vault's vhost and the master password never reaches the server. Its administration is an ordinary grant on http/vault/<instance>, described below. Who may register a vault account is a third thing again, set per instance by open_signups rather than by a grant.

Admin actions are authorised by the path of the resource they touch (creating a DNS zone needs write on that zone, etc.), with whole-system management gated on the */*/* system-admin grant described below.

Git

*/git/<repo>          recommended — every frontend
ssh/git/<repo>        pin to SSH only
ssh/git/*             all repos over SSH (e.g. a read-only CI account)
*/git/<repo>:pulls    the refs/pull/* namespace within one repo

reader — clone and fetch.
writer — push (create and update branches and tags).
owner — everything writer can do, plus delete refs and perform repository-level admin. Whoever runs /git create becomes owner of the new repo automatically.

The one sub-resource is <repo>:pulls — the pull-request ref namespace. writer on it allows opening, updating, and closing PRs without any branch access; paired with a container reader it is the standard contributor grant. A grant on the repo covers :pulls; a :pulls grant covers nothing beyond refs/pull/*. Branch-level grants do not exist. Full walkthrough on the Git access control page.

Mail

Mail is the one backend where the namespace has two levels and where the frontend segment changes which capability you are granting.

namespace = <domain>            whole domain
          = <domain>:<mailbox>  a single mailbox within the domain

The mailbox sub-resource is matched intelligently: a grant on the bare domain (example.com) covers every mailbox in it, and either part may be a wildcard.

imap/mail/example.com            read every mailbox in example.com
imap/mail/example.com:alice      read only alice@example.com
smtp/mail/example.com:alice      send as alice@example.com
smtp/mail/example.com:*          send as any mailbox in example.com
*/mail/example.com:alice         both read and send for alice (any frontend)
*/mail/*:*                       every mailbox, both protocols

Capability mapping:

imap frontend + reader — open and read the mailbox over IMAP.
smtp frontend + writer — authenticated submission: send mail as that mailbox.
owner — implies both of the above (read + send) for the matched mailbox(es).

Because the frontend distinguishes the two capabilities, a read-only mail account is imap/mail/<domain>:<mailbox> reader, while a send-only relay account is smtp/mail/<domain>:<mailbox> writer. Use */mail/... only when you intend to grant both. Inbound delivery (receiving mail) depends on the domain's recipient policy: under the default catch_all policy it is resolved from the recipient address alone, while a domain configured with recipient_policy = "known_users" accepts a recipient only when a user holds a grant on imap/mail/<domain>:<mailbox>. See the Mail docs.

Site

http/site/<name>

reader — view the served site.
writer / owner — confer no additional serving capability; HTTP serving only ever checks read access.

Public sites work by granting the built-in anon user reader on the site path; making a site private (auth=private) removes that anon grant so only users/groups with an explicit grant can read it. Note that publishing content to a site is a Git grant on the underlying store (*/git/<store>), not a site grant — the two are separate. Details on the Private sites and access grants page.

OCI registry

http/oci/<registry>

reader — pull images (manifests and blobs).
writer — push images.
owner — delete tags and manifests.

Namespace is the registry instance name; there are no per-repository sub-grants within a registry. See OCI.

Image

http/image/<instance>

reader — access the instance as a guest.
owner — administer the instance (maps to the image app's admin role; owner is what grants delete/admin capability).

writer exists in the model but the image backend only distinguishes guest (read) from admin (owner). See Images.

Calendar and contacts

http/calendar/<instance>
http/contacts/<instance>

Both CalDAV (calendar) and CardDAV (contacts) map HTTP methods onto roles the same way:

reader — read methods: GET, HEAD, OPTIONS, PROPFIND, REPORT.
writer — mutating methods: PUT, POST, PATCH, MKCOL, DELETE.
owner — implies writer.

The namespace is the instance name; there are no per-collection sub-grants. See Calendar and Contacts.

Files

http/files/<share>

A WebDAV share maps methods onto roles the way the other DAV surfaces do:

reader — read methods: GET, HEAD, OPTIONS, PROPFIND.
writer — everything a file manager does: PUT, MKCOL, DELETE, MOVE, COPY, PROPPATCH, LOCK, UNLOCK.
owner — implies writer, and is what /files create grants its creator.

The namespace is the share name; there are no per-collection sub-grants, so a share is the unit you hand out. See Files.

DNS

DNS queries are authoritative and public — they are answered without authentication. Grants govern zone management performed through the admin SSH session, keyed by zone apex:

ssh/dns/<zone>      e.g. ssh/dns/example.com

reader — view the zone's records.
writer — add and update records in the zone.
owner — delete the zone.

The zone is normalised (trailing dot stripped, lower-cased) before matching. See DNS.

AI

ssh/ai/default

A single fixed namespace. writer (or higher) is required to use the embedded AI prompting in the admin SSH session; reader is not sufficient. See AI.

Vault

http/vault/<instance>

This path governs administration of the instance through the admin console, MCP and the HTTP API — /vault accounts list and /vault accounts delete. /vault create grants its caller owner on the instance it creates.

owner — manage the instance's vault accounts.

Only owner is consulted here; reader and writer carry no vault meaning. A system administrator may administer every instance.

Vault data sits outside this model entirely. The grant governs who may list and delete accounts, not who may read their contents: items are stored as client-encrypted ciphertext, so an instance owner administers accounts without being able to decrypt them. Account registration is governed by the instance's open_signups flag. See Vault.

System administration

*/*/*

owner on */*/* is the system-admin grant — it matches every frontend, every backend, and every namespace, so it satisfies any capability check anywhere. It is what gates whole-system operations such as user and group management in the admin SSH session ("System administrator privileges required").

On first start, if no admin exists, Everlock creates a bootstrap admin account holding owner on */*/* and prints its generated password. Treat this grant as root-equivalent: assign it sparingly, and prefer scoped grants (a specific backend/namespace) for everything that does not genuinely need full control.

How grants combine

A user's effective role on a path is the highest role from any matching source: their own grants and the grants of every group they belong to.
Sources are additive only. There is no deny. To take away access a user has via a group, remove them from the group or revoke the group grant.
Wildcards widen matching per segment; they never narrow it.