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>`	repository name	no	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
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
System admin	`*`	`//*`	everything	—	—	—	full administration

Backends not in this table — OAuth token issuance, the admin HTTP interface, and the vault — 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) 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. What Everlock gates is who may register an account — invite-gated by default, or opened with open_signups — rather than a role-on-access-path grant. A future release will add an http/vault/<instance> grant to tie account creation to this identity registry.

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)

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 namespace is just the repository name; Git has no sub-resource grants (you cannot grant a single branch). 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) is not authorised by grants — it is resolved from the recipient address. 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.

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.

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, every group they belong to, and the implicit self-ownership rule (a path namespace matching their login).
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.