Permissions inheritance that does not collapse

Permissions on a game server start simple and become the thing nobody wants to touch. The usual end state is a file with forty groups, several of which exist because somebody asked once, and no living person who can say what happens if a particular line is removed.

That state is reached the same way every time, and it is avoidable with about an hour of thought at the beginning.

Model roles, not people

The first mistake is granting permissions to individuals. It works for three staff and collapses at eight, because every promotion becomes an audit of one person's list rather than a move between groups.

Define the roles your server actually has (usually four: owner, admin, moderator, trusted player) and grant everything to those. A person's entry should be one line: which group they are in.

If somebody needs a permission their group does not have, that is information. Either the role is wrong or the request is, and both are worth resolving rather than patching with an individual grant, which is the same conversation as deciding who joins the staff team at all, and usually has the same answer.

Inherit upward, never sideways

A moderator's permissions should be a subset of an admin's, and an admin's a subset of the owner's. Each group inherits the one below and adds to it.

What breaks this is a permission granted to moderators and not to admins — usually because a moderator needed something at the time and nobody thought about the hierarchy. Now the ordering is not a hierarchy at all, it is a set of overlapping bundles, and nobody can reason about who can do what without reading every line.

Check for this specifically. It is the single most common structural fault and it is invisible until somebody is surprised.

Negative permissions are a last resort

Most systems support explicitly denying a node, and it is tempting: inherit everything from admin, then take away the dangerous ones.

Resist it. A negative permission means the effective set depends on evaluation order, and evaluation order is the part of any permissions plugin that nobody fully understands. Two negations and an inheritance later, the behaviour is genuinely hard to predict.

Build up from nothing instead. It is more typing once and it is readable forever.

Wildcards are how servers get taken over

* grants every permission, including ones that do not exist yet because you have not installed that plugin.

That is the part people miss. A group with a wildcard gets every node of every plugin added in future, automatically, with no decision from you. The permission you never intended to grant arrives with next month's install.

Give wildcards to the owner group and nowhere else. This is the same argument as flags on a Source server, where z is not the top of a ladder but an unbounded promise.

Write down what each group is for

One line per group, in a comment at the top of the file: what this role does, and who decides who is in it.

It costs nothing and it is what makes the file maintainable in a year. Without it, every group is archaeology, and the safe move becomes never removing anything, which is precisely how the forty-group file happens.

Test by demotion, not by promotion

The useful test is not whether a moderator can do their job. It is whether a moderator can do something they should not.

Take an account, put it in each group, and try the things that would be damaging: can a moderator ban an admin, change the map, access the console, edit another player's permissions? The answers are frequently not what the file appears to say, because inheritance and order have combined into something nobody intended.

Do this once after any structural change. It is twenty minutes and it is the only test that finds the failures that matter — the same reason a backup nobody has restored is not yet a backup.

Negative permissions, and why they spread

Every permissions system lets you deny a node as well as grant one, and the deny is where most collapsed setups started.

It is always reasonable at the time. A group needs everything in a plugin except one command, so you grant the wildcard and deny the exception. Six months later there are forty denials scattered across a dozen groups, each one a patch over a grant that was too broad, and the effective permissions of any user are no longer readable from the configuration.

The rule worth holding is that a denial is a sign the group above it is wrong. If you are denying a node, the grant that made it necessary was too wide, and narrowing the grant is a permanent fix where the denial is a permanent liability.

There is one legitimate use: a temporary restriction on an individual, such as somebody muted or under review. Those should carry an expiry, and a permissions system that supports timed nodes is worth choosing for that reason alone.

When it has already collapsed

If you are inheriting a file that is already forty groups deep, do not refactor it live. Build the replacement structure alongside, move one person into it, test by demotion, then move the rest.

Rewriting permissions on a running server is how staff lose access mid-incident, and that is an expensive way to learn the lesson: the sort of thing that belongs behind a change you have tested somewhere else first rather than applied on a Friday evening.