Matrix Room Adminで「M_FORBIDDEN: 権限がありません」というエラーを修正します。

Matrix ルームの設定を変更したり、ユーザーを削除したり、誰かを追放したり、権限を編集したり、その他の管理操作を実行しようとすると、エラーメッセージが表示されますM_FORBIDDEN: You do not have permission。初心者にとって、このメッセージは混乱を招く可能性があります。なぜなら、Matrix では「管理者」が 2 つの異なる意味を持つからです。サーバー管理者はホームサーバーを制御し、ルーム管理者は特定のルーム内で十分な権限を持ちます。これらは別々の権限システムです。

確実な解決策は、変更を加える前に、どの権限レイヤーが操作をブロックしたかを特定することです。Matrix ルームの認証は、パワーレベルに基づいています。パワーレベルとは、ルームの状態に格納されている数値で、招待、キック、禁止、メッセージの編集、ルーム設定の変更、またはパワーレベル自体の編集を誰が行えるかを決定します。現在の Matrix 仕様では、Matrix Client-Server API 仕様でこれらのルールが定義されています。Synapse は、Synapse Admin API ドキュメントで、サーバー管理者とルーム管理者は別個のものであることを別途文書化しています。

変更を加える前に、重要な4つの価値観を知っておきましょう。

通常、以下の4つの情報が必要です。

• 例えば、あなたのMatrixユーザーIDなど@alice:example.com。
• 例えば、ルームID!abc123:example.com。 のようなルームエイリアスの方#team:example.comが読みやすいですが、多くのAPIは内部ルームIDに基づいて動作します。
• メンバーシップの状態。ほとんどの場合、ルーム管理操作を実行するには、まずルームに参加する必要があります。
• あなたのパワーレベルと、その行動に必要なレベル。

Element Webまたはデスクトップ版では、ルームIDとルームバージョンは「ルーム設定」の「詳細設定」で確認できます。Elementの最新ドキュメントでは、ルーム管理は「ルーム設定」→「役割と権限」にも記載されています。詳しくは、Elementのルーム設定ガイドをご覧ください。

ステップ1：実際にルームに参加していることを確認してください

Matrixは、招待済み、参加済み、退出済み、禁止済みなど、複数のメンバーシップ状態を区別します。ユーザーは通常、joinルームイベントを送信したり、ルームを管理したりするためにメンバーシップ状態を知る必要があります。これは、ホームサーバーの管理者アカウントがルームに参加していない場合、通常のルーム操作が失敗する可能性があるため重要です。

ElementなどのMatrixクライアントを使用している場合は、ルームを開いて、招待ルームや履歴ルームではなく、参加済みのアクティブなルームとして表示されていることを確認してください。Synapseを運用していて、サーバー管理者による復旧パスが必要な場合は、Synapseはローカルユーザーをルームに参加させるための管理者エンドポイントを提供していますが、その操作に関する権限要件についてはドキュメントに記載されています。Synapseルームメンバーシップ管理を参照してください。

この間違いを避けてください。Synapse Admin APIトークンを所持しているからといって、同じアカウントにルームレベルの権限が自動的に付与されるとは限りません。サーバー管理とルーム管理は意図的に区別されています。

ステップ2：自分の役割と、そのアクションに必要なパワーレベルを確認します。

Element では、一般的な権限レベルをメンバー、モデレーター、管理者といった馴染みのある役割として表現します。内部的には、Matrix はラベルではなく数値を評価します。Matrix の仕様では、状態イベントのしきい値以下の一般ユーザー、そのしきい値を超えるモデレーター、編集に必要なレベル以上の管理者という、馴染みのある解釈を推奨していますm.room.power_levels。一般的なルームでは、メンバーには 0、モデレーターには 50、管理者には 100 を使用しますが、ルームでこれらの値をカスタマイズできます。

ルーム設定 → 役割と権限を開きます。自分の役割と実行しようとしている操作の両方を確認してください。Element の現在のドキュメントには、設定の変更、ユーザーの削除、ユーザーの禁止、履歴の表示設定の変更、権限の変更など、一般的な操作が記載されており、それぞれに必要な権限レベルが定められています。

例えば、あなたのアカウントのパワーレベルが50で、ルームの権限変更に100が必要だとします。あなたはモデレーターとして一部の管理タスクを実行することはできますが、権限モデルを編集しようとすると正しくエラーが返されますM_FORBIDDEN。

ステップ3：対象ユーザーと自身の電力を確認する

これは、見落としやすいマトリックスルールの1つです。キックやBAN操作の場合、アクションのしきい値に達するだけでは必ずしも十分ではありません。マトリックスの認証ルールでは、対象ユーザーの権限レベルが、アクションを実行するユーザーよりも低いことも要求されます。

例：あなたのアカウントのレベルが50で、ルームのkick参加レベル上限も50、さらに別のモデレーターもレベル50です。あなたはキックの上限を満たしていますが、同じレベルのモデレーターをキックすることはできません。対象があなたより下位ではないため、認証ルールによって操作が拒否されます。

この同じ原則は、多くの混乱を招くモデレーションの失敗を説明するものです。ルーム管理者は、比較の両側を検証する必要があります。

• あなたの現在のパワーレベル。
• 必要値kickまたはbanしきい値。
• 対象ユーザーの現在の電力レベル。

対象が同等の管理者である場合、通常、別の同等の管理者はそのユーザーの権限を簡単に削除することはできません。Element の高度なルーム管理に関するドキュメントでは、通常のクライアントワークフローでは管理者が他の管理者から管理者権限を削除できないことを明示的に警告しています。Elementの高度なルーム管理を参照してください。

ステップ4：ルーム管理者が利用可能な場合は、既存の管理者を使用する

最も簡単な復旧方法は、技術的な問題ではなく、組織的な問題であることが多いです。他にアクティブなルーム管理者が存在し、十分な権限を持っている場合は、その管理者にルーム設定 → 役割と権限から参加アカウントを昇格させるよう依頼してください。

これは、ルームの状態を手動で操作するよりも好ましい方法です。なぜなら、クライアントは現在の役割モデルを表示し、他のMatrixクライアントと同じ認証ルールを適用するからです。昇格後、元の操作を再試行してください。

それでも失敗する場合は、「管理者」権限があればすべての操作が自動的に許可されると決めつけるのではなく、実際の操作と権限のしきい値を比較してください。カスタム権限レベルイベントでは、特定のイベントタイプに通常とは異なるしきい値を割り当てることができます。

ステップ5：使用可能なルーム管理者がいない場合は、Synapse経由で復旧します。

Synapseホームサーバーを運用していて、アクティブな管理者がいないルームが放置されている場合は、データベースを編集したりルームイベントを捏造したりするのではなく、Synapseがサポートする復旧APIを使用してください。Synapseは、ルーム管理者を作成するAPIを提供しています。

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

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

Synapseサーバー管理者のアクセストークンを使用して、そのリクエストを認証してください。公式のroom-admin APIドキュメントは、Synapse Rooms Admin APIで入手できます。このエンドポイントは、選択されたローカルユーザーに、そのルームでローカルユーザーに利用可能な最高のルーム権限を付与します。必要に応じて、また可能な場合は、そのユーザーを最初に招待することもできます。

復旧コール後、昇格したアカウントでルームに参加または再度開き、Matrixクライアントで操作を再試行してください。

特別ケース：ルームバージョン12以降

Matrix Room バージョン 12 では、作成者の表示方法が変更されました。作成者は実質的に無制限かつ不変の権限レベルを持ち、usersマップ上で通常のユーザーのように表示されません。作成者は通常の権限レベルイベントによって降格されることはありません。この動作については、 Matrix Room バージョン 12 仕様書m.room.power_levelsに記載されています。

つまり、以前のバージョンのルームからコピーしたトラブルシューティング手法は、バージョン12のルームにはそのまま適用できない可能性があります。高度な復旧や電力レベルの編集を行う前に、ルームのバージョンを確認してください。

電力レベルを直接検査する方法

高度なトラブルシューティングを行うには、関連するルーム状態イベントは ですm.room.power_levels。これには次のようなフィールドが含まれます。

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

アカウントが にリストされていない場合users、通常、レベルは に戻りますusers_default。ほとんどのルームでは、これは 0 を意味します。特定のイベントタイプは、マップを通じて一般的な状態またはメッセージのしきい値を上書きすることもできますevents。

クライアントまたはAPIが保持する内容を正確に把握していない限り、電力レベルイベント全体を小さな部分オブジェクトに置き換えないでください。電力レベルの状態には複数の重要なフィールドが含まれている場合があり、それらを誤って削除すると、意図した以上の権限が変更される可能性があります。

やってはいけないこと

• 通常のルームロールの問題を解決するためだけに、Synapseアカウントをサーバー管理者権限に昇格させないでください。必要最小限の権限のみを使用してください。
• 部屋の電力レベルを変更するために、Synapseデータベースの行を編集しないでください。部屋の認証は、データベース内のユーザーフラグではなく、署名付きの部屋イベントによって表されます。
• Synapse を再起動しても、通常の解決策にはなりませんM_FORBIDDEN。認証エラーは通常、古いプロセスが原因ではなく、ルームの状態に関する決定的な判断が原因です。
• クライアントキャッシュをクリアしても、権限が変更されるとは限りません。ホームサーバーが認証ルールを適用します。
• アクセストークンは、シェル履歴、スクリーンショット、サポートチケット、URLなどに公開しないでください。APIAuthorization: Bearer ...を使用する際は、ヘッダーを使用することをお勧めします。

クイック診断表

最終確認

ルームの管理に必要なアカウントが参加し、意図したアクションを実行するのに十分な権限レベルを持ち、403M_FORBIDDENエラーを返さずにそのアクションを実行できる場合、修正は完了です。モデレーションアクションの場合は、Matrix認証ルールで要求されている場合、対象ユーザーの権限レベルが低いことも確認してください。

Matrixの新規管理者にとって最も役立つ考え方はシンプルです。まず、ホームサーバーの権限を扱っているのか、ルームの権限を扱っているのかを特定します。次に、メンバーシップ、権限レベル、アクションのしきい値、および対象ユーザーのレベルを確認します。この手順に従うことで、不要なサーバー変更なしにほとんどの権限エラーを解決できます。