From 49765e0e0a82a13f29aca7f5ed0f94d9ed3ef362 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Wed, 29 May 2024 09:42:19 +0100 Subject: [PATCH] Clarify that redaction events are subject to auth rules (#1824) Signed-off-by: Matthias Ahouansou --- .../newsfragments/1824.clarification | 1 + content/rooms/fragments/v8-auth-rules.md | 18 ++++++++++++------ content/rooms/v10.md | 18 ++++++++++++------ content/rooms/v11.md | 18 ++++++++++++------ content/rooms/v3.md | 17 +++++++++++------ content/rooms/v6.md | 18 ++++++++++++------ content/rooms/v7.md | 18 ++++++++++++------ 7 files changed, 72 insertions(+), 36 deletions(-) create mode 100644 changelogs/room_versions/newsfragments/1824.clarification diff --git a/changelogs/room_versions/newsfragments/1824.clarification b/changelogs/room_versions/newsfragments/1824.clarification new file mode 100644 index 00000000..6f830830 --- /dev/null +++ b/changelogs/room_versions/newsfragments/1824.clarification @@ -0,0 +1 @@ +Clarify that redaction events are still subject to all applicable auth rules. diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 3f1a4558..3571057e 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -1,12 +1,6 @@ Events must be signed by the server denoted by the `sender` property. -`m.room.redaction` events are not explicitly part of the auth rules. -They are still subject to the minimum power level rules, but should always -fall into "10. Otherwise, allow". Instead of being authorized at the time -of receipt, they are authorized at a later stage: see the -[Redactions](#redactions) section below for more information. - The types of state events that affect authorization are: - [`m.room.create`](/client-server-api#mroomcreate) @@ -21,6 +15,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the _redact +level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v10.md b/content/rooms/v10.md index ea8c9c94..8ec4832a 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -76,12 +76,6 @@ correctly structured are rejected under the authorization rules below. Events must be signed by the server denoted by the `sender` property. -`m.room.redaction` events are not explicitly part of the auth rules. -They are still subject to the minimum power level rules, but should always -fall into "10. Otherwise, allow". Instead of being authorized at the time -of receipt, they are authorized at a later stage: see the -[Redactions](#redactions) section below for more information. - The types of state events that affect authorization are: - [`m.room.create`](/client-server-api#mroomcreate) @@ -96,6 +90,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the _redact +level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling redactions](#handling-redactions) section. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v11.md b/content/rooms/v11.md index 6f5d772d..782edb3e 100644 --- a/content/rooms/v11.md +++ b/content/rooms/v11.md @@ -83,12 +83,6 @@ such events over the Client-Server API. Events must be signed by the server denoted by the `sender` property. -`m.room.redaction` events are not explicitly part of the auth rules. -They are still subject to the minimum power level rules, but should always -fall into "10. Otherwise, allow". Instead of being authorized at the time -of receipt, they are authorized at a later stage: see the -[Redactions](#redactions) section below for more information. - The types of state events that affect authorization are: - [`m.room.create`](/client-server-api#mroomcreate) @@ -103,6 +97,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the _redact +level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling redactions](#handling-redactions) section. +{{% /boxes/note %}} + The rules are as follows: 1. {{< changed-in this="true" >}} diff --git a/content/rooms/v3.md b/content/rooms/v3.md index dd2fd144..ad9ff698 100644 --- a/content/rooms/v3.md +++ b/content/rooms/v3.md @@ -89,12 +89,17 @@ The complete structure of a event in a v3 room is shown below. ### Authorization rules -{{< added-in this=true >}} `m.room.redaction` events are no longer -explicitly part of the auth rules. They are still subject to the -minimum power level rules, but should always fall into "11. Otherwise, -allow". Instead of being authorized at the time of receipt, they are -authorized at a later stage: see the [Handling Redactions](#handling-redactions) -section below for more information. +{{% boxes/note %}} +{{< added-in this=true >}} `m.room.redaction` events are subject to auth rules in +the same way as any other event. In practice, that means they will normally be allowed +by the auth rules, unless the `m.room.power_levels` event sets a power level requirement +for `m.room.redaction`events via the `events` or `events_default` properties. In +particular, the _redact level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section. +{{% /boxes/note %}} {{< rver-fragment name="v3-auth-rules" withVersioning=true >}} diff --git a/content/rooms/v6.md b/content/rooms/v6.md index b0309254..9761ffdb 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -40,12 +40,6 @@ in [room version 5](/rooms/v5). ### Authorization rules -`m.room.redaction` events are not explicitly part of the auth rules. -They are still subject to the minimum power level rules, but should always -fall into "10. Otherwise, allow". Instead of being authorized at the time -of receipt, they are authorized at a later stage: see the -[Handling Redactions](#handling-redactions) section below for more information. - {{< added-in this=true >}} Rule 4, which related specifically to events of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass authorization checks relating to state events. @@ -71,6 +65,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the _redact +level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v7.md b/content/rooms/v7.md index eda351d0..b5c0f28a 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -37,12 +37,6 @@ new point for `membership=knock` is added. Events must be signed by the server denoted by the `sender` property. -`m.room.redaction` events are not explicitly part of the auth rules. -They are still subject to the minimum power level rules, but should always -fall into "10. Otherwise, allow". Instead of being authorized at the time -of receipt, they are authorized at a later stage: see the -[Redactions](#redactions) section below for more information. - The types of state events that affect authorization are: - [`m.room.create`](/client-server-api#mroomcreate) @@ -57,6 +51,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the _redact +level_ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling redactions](#handling-redactions) section. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: