diff --git a/changelogs/room_versions/newsfragments/1824.clarification b/changelogs/room_versions/newsfragments/1824.clarification new file mode 100644 index 000000000..6f8308305 --- /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 3f1a4558a..3571057e2 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 1d366c8c6..a4b8806a1 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 5d44161c2..c0c5b36a1 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 dd2fd144a..ad9ff698b 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 b0309254d..9761ffdb1 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 eda351d0c..b5c0f28ab 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`: