Epic #49
Updated by Bricklou 9 days ago
Anyone with an account can currently do anything the platform exposes. Administrators need Some peoples don't necessarily want to decide who may do what, and people who own a server need to share give all access to it without handing over other users. To avoid this, the whole installation. This epic covers what the platform knows how manager should allow administrators to authorise, who can be given access, how access is given, how it is decided and enforced, how it can be understood afterwards, how accounts are administered, and how agents and modules prove who they are. The model, in short: * A permission is a named capability, for example "restart a Minecraft server". Permissions are contributed by the platform itself and by installed modules. * A role is a reusable named set of permissions. A group is a named set of users and holds no permissions of its own. * Access is given by granting a role, or a hand-picked set of permissions, restrict accesses to a user or a group — either across the whole platform or on one specific object. * Three states exist: allowed, denied, not set. Not set is not the same as denied. * The grant closest to the object decides. Within one place, an entry naming the person beats one naming a group they are in, and a denial beats an allowance. Anything not decided is refused. * Administrators (holders of the all-permissions role) are never refused, and the last of them cannot be removed. * Nobody can give away access they do not hold themselves. Out of scope here, tracked separately: folders and the inheritance that comes with them, storing and browsing an audit trail (this epic only emits the events), bulk operations, and hosting several organisations on one installation. Full specification: `documents/kubestro-permissions-report.md`. permissions.