Beheben Sie die Fehlermeldung „M_FORBIDDEN: Sie haben keine Berechtigung“ in der Matrix-Raumverwaltung.

Sie versuchen, eine Matrix-Raumeinstellung zu ändern, einen Benutzer zu entfernen, jemanden zu sperren, Berechtigungen zu bearbeiten oder eine andere administrative Aktion durchzuführen und erhalten eine Fehlermeldung M_FORBIDDEN: You do not have permission. Für Neulinge kann diese Meldung verwirrend sein, da „Admin“ in Matrix zwei verschiedene Bedeutungen haben kann: Ein Serveradministrator steuert den Homeserver, während ein Raumadministrator über ausreichende Berechtigungen innerhalb eines bestimmten Raums verfügt. Es handelt sich dabei um separate Berechtigungssysteme.

Die zuverlässigste Lösung besteht darin, die Berechtigungsebene zu identifizieren, die die Aktion blockiert hat, bevor Änderungen vorgenommen werden. Die Autorisierung von Matrix-Räumen basiert auf Machtstufen : Im Raumstatus gespeicherte Zahlen bestimmen, wer einladen, kicken, bannen, Nachrichten bearbeiten, Raumeinstellungen ändern oder die Machtstufen selbst bearbeiten darf. Die aktuelle Matrix-Spezifikation definiert diese Regeln in der Matrix Client-Server API-Spezifikation . Synapse dokumentiert separat in der Synapse Admin API-Dokumentation , dass ein Serveradministrator sich von einem Raumadministrator unterscheidet .

Bevor Sie irgendetwas ändern: Kennen Sie die vier wichtigsten Werte.

Sie benötigen in der Regel vier Informationen:

• Ihre Matrix-Benutzer-ID , zum Beispiel @alice:example.com.
• Die Raum-ID zum Beispiel !abc123:example.com. Ein Raumalias wie #team:example.comist leichter lesbar, aber viele APIs arbeiten mit der internen Raum-ID.
• Ihr Mitgliedschaftsstatus . In den meisten Fällen müssen Sie dem Raum beigetreten sein, bevor Sie Raumverwaltungsaktionen durchführen können.
• Dein Kraftniveau und das für die Aktion erforderliche Niveau .

In Element Web oder Desktop finden Sie die Raum-ID und die Raumversion in den Raumeinstellungen unter „Erweitert“. Die aktuelle Dokumentation von Element führt die Raumverwaltung ebenfalls unter „Raumeinstellungen“ → „Rollen & Berechtigungen“ auf . Siehe den Leitfaden zu den Raumeinstellungen von Element .

Schritt 1: Vergewissern Sie sich, dass Sie tatsächlich dem Raum beigetreten sind.

Matrix unterscheidet verschiedene Mitgliedschaftsstatus, darunter eingeladen, beigetreten, verlassen und gesperrt. Ein Benutzer benötigt in der Regel den joinMitgliedschaftsstatus, um Raumereignisse zu senden oder den Raum zu verwalten. Dies ist wichtig, da ein Administratorkonto auf dem Heimserver eine normale Raumaktion fehlschlagen lassen kann, wenn dieses Konto nicht am Raum teilnimmt.

Wenn Sie einen Matrix-Client wie Element verwenden, öffnen Sie den Raum und vergewissern Sie sich, dass er als aktiver, Ihnen beigetretener Raum angezeigt wird und nicht nur als Einladung oder historischer Raum. Falls Sie Synapse verwenden und einen Wiederherstellungspfad für Serveradministratoren benötigen, bietet Synapse einen Administrator-Endpunkt zum Hinzufügen eines lokalen Benutzers zu einem Raum. Die Berechtigungsanforderungen für diesen Vorgang sind jedoch weiterhin dokumentiert. Siehe Synapse-Raummitgliedschaftsverwaltung .

Vermeiden Sie diesen Fehler: Gehen Sie nicht davon aus, dass der Besitz eines Synapse-Admin-API-Tokens automatisch dem gleichen Konto Berechtigungen auf Raumebene verleiht. Server- und Raumverwaltung sind bewusst getrennt.

Schritt 2: Überprüfen Sie Ihre Rolle und die für die Aktion erforderliche Berechtigungsstufe.

Element stellt gängige Berechtigungsstufen anhand bekannter Rollen wie Mitglied, Moderator und Administrator dar. Matrix hingegen wertet Zahlen anstelle von Bezeichnungen aus. Die Matrix-Spezifikation empfiehlt die gewohnte Interpretation: Normale Benutzer unterhalb des Schwellenwerts für Statusereignisse, Moderatoren oberhalb dieses Schwellenwerts und Administratoren mit oder über der für Bearbeitungen erforderlichen Berechtigungsstufe m.room.power_levels. Typische Räume verwenden üblicherweise 0 für Mitglieder, 50 für Moderatoren und 100 für Administratoren; diese Werte können jedoch individuell angepasst werden.

Öffnen Sie die Raumeinstellungen → Rollen & Berechtigungen . Überprüfen Sie sowohl Ihre Rolle als auch die geplante Aktion. Die aktuelle Dokumentation von Element listet gängige Aktionen wie das Ändern von Einstellungen, das Entfernen und Sperren von Benutzern, das Ändern der Verlaufssichtbarkeit und das Ändern von Berechtigungen auf, jeweils mit den erforderlichen Berechtigungen.

Angenommen, Ihr Konto hat beispielsweise Berechtigungsstufe 50 und der Raum erfordert Stufe 100, um Berechtigungen zu ändern. Sie können weiterhin Moderator sein und einige administrative Aufgaben ausführen, aber der Versuch, das Berechtigungsmodell zu bearbeiten, wird erwartungsgemäß fehlschlagen M_FORBIDDEN.

Schritt 3: Überprüfen Sie sowohl den Zielbenutzer als auch Ihre eigene Leistung.

Dies ist eine der am leichtesten zu übersehenden Matrix-Regeln. Für Kick- und Bannvorgänge reicht es nicht immer aus, den Aktionsschwellenwert zu erreichen. Die Autorisierungsregeln von Matrix setzen außerdem voraus, dass der Zielnutzer eine niedrigere Machtstufe als derjenige besitzt, der die Aktion ausführt.

Beispiel: Ihr Account hat Level 50, die Raumschwelle kickliegt bei 50 und ein anderer Moderator hat ebenfalls Level 50. Sie erfüllen die Kick-Schwelle, können den Moderator mit gleichem Level aber trotzdem nicht kicken. Die Autorisierungsregeln lehnen die Operation ab, da das Ziel nicht unter Ihrem Level liegt.

Dieses Prinzip erklärt viele verwirrende Moderationsfehler. Ein Raumadministrator sollte beide Seiten des Vergleichs prüfen:

• Ihr aktueller Leistungspegel.
• Die erforderliche kickSchwelle ban.
• Der aktuelle Leistungspegel des Zielnutzers.

Wenn es sich bei dem Ziel um einen Administrator mit gleichen Berechtigungen handelt, kann ein anderer Administrator mit gleichen Berechtigungen diesem Benutzer normalerweise nicht einfach die Berechtigung entziehen. Die Dokumentation zur erweiterten Raumverwaltung von Element weist ausdrücklich darauf hin, dass Administratoren im normalen Client-Workflow keine Administratorberechtigungen von anderen Administratoren entfernen können. Siehe „ Erweiterte Raumverwaltung von Element“ .

Schritt 4: Verwenden Sie einen vorhandenen Raumadministrator, falls einer verfügbar ist.

Die einfachste Lösung ist in der Regel organisatorischer und nicht technischer Natur. Falls ein anderer aktiver Raumadministrator mit ausreichenden Berechtigungen existiert, bitten Sie diesen, Ihr beigetretenes Konto unter Raumeinstellungen → Rollen & Berechtigungen hochzustufen .

Dies ist der manuellen Bearbeitung des Raumstatus vorzuziehen, da der Client das aktuelle Rollenmodell anzeigt und dieselben Autorisierungsregeln wie jeder andere Matrix-Client anwendet. Nach der Heraufstufung wiederholen Sie die ursprüngliche Aktion.

Falls dies weiterhin fehlschlägt, vergleichen Sie die genaue Aktion mit dem Berechtigungsschwellenwert, anstatt anzunehmen, dass „Admin“ bedeutet, dass jede Aktion automatisch erlaubt ist. Benutzerdefinierte Leistungsstufenereignisse können bestimmten Ereignistypen ungewöhnliche Schwellenwerte zuweisen.

Schritt 5: Falls kein nutzbarer Raumadministrator mehr vorhanden ist, Wiederherstellung über Synapse durchführen.

Wenn Sie den Synapse-Homeserver betreiben und ein Raum ohne aktiven Administrator zurückgelassen wurde, verwenden Sie die von Synapse unterstützten Wiederherstellungs-APIs, anstatt die Datenbank zu bearbeiten oder Raumereignisse zu erstellen. Synapse bietet eine API zum Erstellen eines Raumadministrators :

POST /_synapse/admin/v1/rooms/<room_id_or_alias>/make_room_admin

{
  "user_id": "@alice:example.com"
}

Authentifizieren Sie diese Anfrage mit dem Zugriffstoken eines Synapse- Serveradministrators . Die offizielle Dokumentation der Room-Admin-API finden Sie unter Synapse Rooms Admin API . Der Endpunkt gewährt dem ausgewählten lokalen Benutzer die höchste im jeweiligen Raum verfügbare Berechtigung; falls erforderlich und möglich, kann er diesen Benutzer zuerst einladen.

Nach dem Wiederherstellungsanruf können Sie dem Raum mit dem beförderten Konto beitreten oder ihn erneut öffnen und die Aktion im Matrix-Client erneut versuchen.

Sonderfall: Raumversion 12 und höher

Matrix-Raumversion 12 ändert die Darstellung von Erstellern. Der Ersteller verfügt über eine praktisch unbegrenzte, unveränderliche Machtstufe und wird nicht wie ein normaler Benutzer in der usersKarte aufgeführt m.room.power_levels. Ein Ersteller kann nicht durch ein normales Machtstufenereignis herabgestuft werden. Dieses Verhalten ist in der Spezifikation von Matrix-Raumversion 12 dokumentiert .

Das bedeutet, dass eine Fehlerbehebungsmethode, die von einer älteren Raumversion übernommen wurde, möglicherweise nicht unverändert auf einen Raum der Version 12 anwendbar ist. Überprüfen Sie die Raumversion, bevor Sie erweiterte Wiederherstellungsmaßnahmen oder Änderungen an den Energieeinstellungen vornehmen.

Wie man Leistungspegel direkt prüft

Für die erweiterte Fehlerbehebung ist das relevante Raumstatusereignis m.room.power_levels. Es enthält Felder wie:

{
  "users_default": 0,
  "state_default": 50,
  "invite": 0,
  "kick": 50,
  "ban": 50,
  "redact": 50,
  "users": {
    "@alice:example.com": 100,
    "@bob:example.com": 50
  }
}

Wenn Ihr Konto nicht unter „Konto“ aufgeführt ist users, wird sein Level normalerweise auf „Level 0“ zurückgesetzt users_default. Für die meisten Räume bedeutet das 0. Bestimmte Ereignistypen können die allgemeinen Status- oder Nachrichtenschwellenwerte auch über die eventsKarte überschreiben.

Ersetzen Sie das gesamte Energielevel-Ereignis nicht durch ein kleines Teilobjekt, es sei denn, Sie wissen genau, welche Daten der Client oder die API beibehalten wird. Der Energielevel-Status kann mehrere wichtige Felder enthalten, und deren versehentliches Löschen kann mehr Berechtigungen ändern als beabsichtigt.

Was man nicht tun sollte

• Ein Synapse-Konto sollte nicht nur deshalb zum Serveradministrator befördert werden, um ein gewöhnliches Problem mit einer Raumrolle zu lösen. Verwenden Sie nur die geringstmöglichen Berechtigungen.
• Ändern Sie die Raumleistungsstufen nicht durch Bearbeiten der Synapse-Datenbankzeilen. Die Raumautorisierung erfolgt durch signierte Raumereignisse und nicht einfach durch ein Benutzerkennzeichen in der Datenbank.
• Starten Sie Synapse nicht routinemäßig neu, um das Problem zu beheben M_FORBIDDEN. Autorisierungsfehler sind in der Regel auf deterministische Raumstatusentscheidungen zurückzuführen und nicht auf Probleme mit veralteten Prozessen.
• Gehen Sie nicht davon aus, dass das Löschen des Client-Caches die Berechtigungen ändert. Der Homeserver setzt die Autorisierungsregel durch.
• Zugriffstoken dürfen nicht in der Shell-Historie, Screenshots, Support-Tickets oder URLs veröffentlicht werden. Verwenden Sie stattdessen einen Authorization: Bearer ...Header bei der Nutzung von APIs.

Schnelldiagnosetabelle

Abschließende Überprüfung

Die Behebung des Problems ist abgeschlossen, sobald das Konto, das den Raum verwalten soll, beigetreten ist, über ausreichende Berechtigungen für die beabsichtigte Aktion verfügt und diese Aktion ohne 403- M_FORBIDDENFehler ausführen kann. Bei Moderationsaktionen ist außerdem zu prüfen, ob die Berechtigungen des Zielbenutzers niedriger sind, wenn dies die Matrix-Autorisierungsregeln erfordern.

Für einen neuen Matrix-Administrator ist ein einfaches Vorgehen am hilfreichsten: Zuerst sollte man feststellen, ob es sich um Berechtigungen für den Homeserver oder für einen Raum handelt . Anschließend prüft man die Mitgliedschaft, die eigene Berechtigungsstufe, den Aktionsschwellenwert und die Berechtigungsstufe des Zielbenutzers. Mit dieser Vorgehensweise lassen sich die meisten Berechtigungsfehler ohne unnötige Serveränderungen beheben.