Discord-Berechtigungen erklärt: Rollenhierarchie, Kanal-Overwrites und die Reihenfolge, in der sie greifen

Discord-Berechtigungen wirken unberechenbar, weil zwei unabhängige Systeme kombiniert werden und fast niemand die Reihenfolge liest, in der das geschieht. Kennt man sie, wird das Verhalten vollständig deterministisch, und die meisten Berechtigungsfehler werden offensichtlich statt rätselhaft.

Zwei Systeme, nicht eines

Das erste System sind Rechte auf Serverebene. Jede Rolle trägt eine Menge von Berechtigungs-Flags, gespeichert als Bitfeld, und ein Mitglied hält die Vereinigung aller Flags seiner Rollen. Das ist additiv: Gewährt irgendeine Rolle „Nachrichten verwalten", hat das Mitglied dieses Recht serverweit. Auf dieser Ebene lässt sich nichts entziehen.

Das zweite System sind Kanal-Overwrites. Jeder Kanal kann Allow- und Deny-Einträge für einzelne Rollen und einzelne Mitglieder tragen. Nur hier lässt sich ein Recht entziehen. Dass Subtraktion ausschließlich auf Kanalebene existiert, erklärt den größten Teil der Verwirrung mit diesem System.

Die exakte Auswertungsreihenfolge

Discords Entwicklerdokumentation gibt die Abfolge genau an. Zuerst greifen die Basisrechte von @everyone auf Serverebene. Dann kommen die Rechte der Rollen des Mitglieds auf Serverebene hinzu. Danach auf Kanalebene: @everyone-Denies, @everyone-Allows, Rollen-Denies, Rollen-Allows, mitgliedsspezifische Denies und zuletzt mitgliedsspezifische Allows.

Daraus folgen sofort zwei Dinge. Allows schlagen Denies auf derselben Ebene, weil das Allow danach angewendet wird. Und mitgliedsspezifische Overwrites schlagen jede rollenbasierte Regel — das macht sie zu einem praktischen Ausnahmemechanismus und zu einer schlechten Gewohnheit, denn ein Member-Overwrite ist in deinem Rollenmodell unsichtbar und innerhalb eines Monats vergessen.

Administrator ist keine Berechtigung, sondern eine Umgehung

Die Dokumentation ist deutlich: Administrator erlaubt alle Berechtigungen und umgeht Kanal-Overwrites. Die Auswertung bricht ab — hat das Mitglied dieses Flag, liefert die Berechnung sofort alles zurück und erreicht die Overwrite-Stufe nie.

Das heißt: Ein Admin kann nicht aus einem privaten Kanal ausgeschlossen werden, unterliegt keinem Slowmode, und man kann mit ihm nicht testen, ob das Berechtigungsmodell funktioniert. Es heißt außerdem, dass jede Administrator-Rolle eine vollständige Kompromittierung des Servers ist, sobald dieses Konto übernommen wird. Gib Moderatoren stattdessen die konkreten Flags, die sie brauchen; die zehn Minuten Mehraufwand sind die günstigste Sicherheit, die du je kaufen wirst.

Hierarchie gilt für Handlungen, nicht für Sichtbarkeit

Das ist das häufigste Missverständnis. Die vertikale Reihenfolge der Rollen in den Servereinstellungen bestimmt, wer wen moderieren darf: Man kann nur Mitglieder kicken, bannen oder deren Rollen ändern, die unterhalb der eigenen höchsten Rolle stehen. Sie bestimmt nicht, welche Berechtigung in einem Kanal gewinnt. Die Reihenfolge der Rollen in der Kanal-Rechteliste hat überhaupt keine Priorität.

Hat ein Mitglied also eine „Stumm"-Rolle, die das Schreiben in einem Kanal verbietet, und eine „Mitglied"-Rolle, die es erlaubt, entscheidet nicht die Hierarchie, sondern die Auswertungsreihenfolge — und das später angewendete Allow gewinnt. Deshalb müssen Mute-Rollen auf Kanalebene verbieten und dürfen von keiner anderen Rolle des Mitglieds wieder erlaubt werden.

Das Modell entwerfen, bevor du irgendwo klickst

Ein Rollenmodell, das Wachstum übersteht, trennt drei Dinge, die Server gewohnheitsmäßig vermischen. Zugriffsrollen entscheiden, was ein Mitglied sieht. Identitätsrollen sind kosmetisch oder selbst vergeben und tragen keine Rechte. Teamrollen tragen Fähigkeiten. Diese Trennung erlaubt dir, eine Farbrolle zu vergeben, ohne versehentlich Zugriff zu gewähren — und Zugriffe umzubauen, ohne jemandes Identität anzufassen.

Setze @everyone als Grundlinie und behandle sie als Definition dessen, was ein Fremder darf. In einem geschlossenen Server ist das nahezu nichts. Jede Zugriffsrolle fügt danach nur hinzu. Wenn du @everyone in zwanzig einzelnen Kanälen Dinge verbietest, ist deine Grundlinie falsch und gehört auf Serverebene enger gesetzt.

Die Berechtigungen, die einen zweiten Blick verdienen

Eine Handvoll Flags ist deutlich gefährlicher, als sie aussieht. „Rollen verwalten" erlaubt es, jede Berechtigung unterhalb der eigenen höchsten Rolle weiterzugeben — ein Pfad zur Rechteausweitung. „Webhooks verwalten" erlaubt es, einen Endpunkt anzulegen, der im Namen beliebiger Absender postet. „@everyone erwähnen" ist ein Spam-Verstärker, sobald ein Moderationskonto übernommen wird. „Kanäle verwalten" erlaubt es, die Spuren all dessen zu löschen.

Keines davon gehört auf eine breit vergebene Rolle, und jedes Konto, das sie hält, sollte Zwei-Faktor-Authentifizierung aktiviert haben — Discord verlangt 2FA für Moderatoren bei Servern, die in die Server-Discovery wollen, und die Anforderung ist auch unabhängig davon sinnvoll.

Richtig testen

Discords eigene Rechtevorschau in den Kanaleinstellungen beantwortet die Frage, was eine Rolle hier sehen darf, erfasst aber keine Wechselwirkungen zwischen Rollen. Der belastbare Test ist ein Konto ganz ohne Rollen plus ein zweites Konto mit genau der Rolle, die du prüfst. Zehn Minuten mit zwei Testkonten finden mehr Probleme als eine Stunde im Einstellungsmenü.

Und schreib das Modell auf. Ein kurzes Dokument, das jede Rolle, ihre Rechte und die von ihr geöffnete Kategorie auflistet, ist der Unterschied zwischen einem Server, den man einem neuen Moderator übergeben kann, und einem, den nur sein Erbauer versteht. Wenn niemand rekonstruieren kann, warum ein Recht existiert, wird es irgendwann beim Aufräumen entfernt — und etwas geht leise kaputt.

Kategorien, Vererbung und synchronisierte Kanäle

Ein Kanal, der in einer Kategorie erstellt wird, übernimmt deren Overwrites im Moment der Erstellung und gilt danach als synchronisiert. Solange er das bleibt, wirken spätere Änderungen an der Kategorie auch auf ihn. Sobald du die Rechte dieses Kanals direkt bearbeitest, desynchronisiert er und bekommt keine Kategorieänderungen mehr — lautlos, mit nur einem kleinen Hinweis in der Oberfläche.

Das ist der Mechanismus hinter der häufigsten Beschwerde: Ein Admin ändert eine Kategorie, elf Kanäle aktualisieren sich, einer nicht — und niemand erinnert sich, dass genau dieser Kanal vor einem halben Jahr einmal angepasst wurde. Die Disziplin dagegen: Zugriffsentscheidungen immer auf Kategorieebene treffen und einen desynchronisierten Kanal als dokumentierte Ausnahme behandeln, nicht als Bequemlichkeit.

Ein durchgerechnetes Beispiel

Nimm ein Mitglied mit den Rollen Mitglied und Contributor in einem Kanal, in dem @everyone das Senden verboten ist, Mitglied es erlaubt ist und das Mitglied ein persönliches Verbot hat, weil es stummgeschaltet wurde. Die Auswertung läuft: Basisrechte von @everyone, dann die Vereinigung von Mitglied und Contributor auf Serverebene, dann das @everyone-Verbot im Kanal, dann die @everyone-Erlaubnis, dann Rollen-Verbote, dann Rollen-Erlaubnisse — was das Senden wieder aktiviert — und zuletzt das mitgliedsspezifische Verbot, das es erneut entzieht.

Das Mitglied kann nicht posten, und der Grund liegt im letzten Schritt, nicht im ersten. Ändere ein Detail — mache aus dem Mute ein Rollen-Verbot statt eines Mitglieds-Verbots — und die danach angewendete Erlaubnis der Rolle Mitglied gewinnt: Der Mute scheitert lautlos. Deshalb werden Mute-Rollen auf Mitgliedsebene umgesetzt oder als Verbot auf einer Rolle, bei der keine andere Rolle dasselbe Recht im selben Kanal wieder erlaubt.

Bots haben auch Rollen, und ihre Position zählt

Ein Bot ist ein Mitglied mit einer Rolle und unterliegt derselben Hierarchieregel wie ein Mensch: Er kann nur Rollen vergeben oder entziehen, die unterhalb seiner eigenen höchsten Rolle liegen. Das mit Abstand häufigste Bot-Support-Ticket überhaupt ist eine fehlgeschlagene Rollenvergabe, weil die Bot-Rolle unter die zu vergebende Rolle gezogen wurde.

Zwei Gewohnheiten verhindern das. Halte Bot-Rollen direkt unter den Teamrollen und über allem, was sie verwalten sollen. Und sortiere Rollen nie um, ohne zu prüfen, was die Bots erreichen müssen. Ein Bot, der still aufgehört hat, Rollen zu vergeben, meldet den Fehler in der Regel nicht — Mitglieder bekommen einfach keine mehr.

Ein kaputtes Berechtigungsmodell reparieren

Berechtigungen auf einem laufenden Server neu zu bauen ist auf genau eine Weise riskant: Für ein paar Minuten sehen Leute Dinge, die sie nicht sehen sollten. Die Reihenfolge mit der geringsten Offenlegung ist, zuerst die Grundlinie zuzuziehen und danach zu öffnen. Setze @everyone auf Serverebene auf das Minimum, prüfe, dass die privaten Kategorien noch privat sind, und füge dann die Zugriffsrollen einzeln wieder hinzu.

Arbeite mit einem schriftlichen Zielmodell statt durch Klicken, und prüfe jeden Schritt mit einem Testkonto, das genau eine Rolle hält. Rechne damit, dass mindestens ein Kanal mit einem vergessenen Mitglieds-Overwrite auftaucht; das ist normal, und ihn zu finden ist der Sinn der Übung.

Zwei-Faktor-Pflicht ist eine Servereinstellung

Discord bietet eine Servereinstellung, die Zwei-Faktor-Authentifizierung für alle Mitglieder verlangt, die Moderationshandlungen ausführen. Sie einzuschalten schwächt nichts und schließt den realistischsten Angriffsweg auf eine Community: nicht ein cleverer Exploit, sondern ein Moderationskonto mit wiederverwendetem Passwort.

Die Anforderung taucht außerdem in Discords Kriterien für die Server-Discovery auf — wer öffentlich gelistet werden will, braucht sie ohnehin. Früh zu aktivieren ist leichter, als sie nachzurüsten, wenn schon ein Dutzend Leute Moderationsrollen halten.