Everlock 0.7.0
The 0.7.0 release tightens who may do what. Access now derives solely from explicit grants, git repositories can hand out a contributor role that opens pull requests without touching branches, and vau
Documentation
Tag: security
Permissions reference — backends, paths, and roles
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 i
Git access control and grants
Everlock uses a path-based grant system to control who can read from and push to repositories. Every access decision — clone, push, admin action — is checked against a table of grants attached to user
Private sites and access grants
By default, every site Everlock creates is public: anyone who can reach the server over HTTP can read the pages. Public access is expressed through the built-in `anon` user having `Reader` on `http/si
Users, groups, and access control
Everlock has a single unified user model shared across all frontends and backends. The same user identity that authenticates over SSH to push a Git repository is also the one that authenticates to an
Managing users
All user management happens from the admin SSH console. This page covers creating users, managing passwords, listing users, and where a new user's access comes from. /users create <login> <password> E