Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

events with rejected_auth_events must be rejected #1137

Merged
merged 2 commits into from Jul 5, 2022
Merged

events with rejected_auth_events must be rejected #1137

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c3adb4f
events with rejected_auth_events must be rejected
richvdh Jun 17, 2022
97d373c
Apply `m.federate` check to the create event in the room state
richvdh Jul 4, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions changelogs/room_versions/newsfragments/1137.clarification
View file
Open in desktop
@@ -0,0 +1 @@
For room versions 1 through 10, clarify that events with rejected `auth_events` must be rejected.
39 changes: 21 additions & 18 deletions content/rooms/fragments/v1-auth-rules.md
View file
Open in desktop
Expand Up @@ -26,22 +26,25 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
the create event, reject.
5. If type is `m.room.aliases`:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this really a check on the auth_events or is it a check on the event being inspected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

multiplied by however many times it shows up in this PR

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the question. It's a check on the m.room.create event which is referred to in the auth_events of the event being inspected.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't the server be using the m.room.create event from the room rather than auth_events though? It feels more understandable to move this point back up a level rather than nest it unmodified into the auth_events checks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possibly, but that seems to be a change to its meaning. Currently we have:

  1. If event does not have a m.room.create in its auth_events, reject.
  2. If the create event...

It's not entirely clear which create event it is talking about in 4, but given the context from 3, surely it's the one from the auth_events.

This is all related to #1136.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hrrrm, actually, looking at the source to Synapse, it does appear to apply the test to the create event in the room state, so I guess that's an argument that we should make that explicit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've updated this to make it apply to the room state, rather than the auth events.

3. If type is `m.room.aliases`:
1. If event has no `state_key`, reject.
2. If sender's domain doesn't matches `state_key`, reject.
3. Otherwise, allow.
6. If type is `m.room.member`:
4. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `membership` is `join`:
1. If the only previous event is an `m.room.create` and the
Expand Down Expand Up @@ -98,15 +101,15 @@ The rules are as follows:
than the `sender`'s power level, allow.
3. Otherwise, reject.
6. Otherwise, the membership is unknown. Reject.
7. If the `sender`'s current membership state is not `join`, reject.
8. If type is `m.room.third_party_invite`:
5. If the `sender`'s current membership state is not `join`, reject.
6. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
9. If the event type's *required power level* is greater than the
7. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
10. If the event has a `state_key` that starts with an `@` and does not
8. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
11. If type is `m.room.power_levels`:
9. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
Expand All @@ -130,14 +133,14 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
12. If type is `m.room.redaction`:
10. If type is `m.room.redaction`:
1. If the `sender`'s power level is greater than or equal to the
*redact level*, allow.
2. If the domain of the `event_id` of the event being redacted is
the same as the domain of the `event_id` of the
`m.room.redaction`, allow.
3. Otherwise, reject.
13. Otherwise, allow.
11. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
37 changes: 20 additions & 17 deletions content/rooms/fragments/v3-auth-rules.md
View file
Open in desktop
Expand Up @@ -33,22 +33,25 @@ The complete list of rules, as of room version 3, is as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
the create event, reject.
5. If type is `m.room.aliases`:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
3. If type is `m.room.aliases`:
1. If event has no `state_key`, reject.
2. If sender's domain doesn't matches `state_key`, reject.
3. Otherwise, allow.
6. If type is `m.room.member`:
4. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `membership` is `join`:
1. If the only previous event is an `m.room.create` and the
Expand Down Expand Up @@ -105,15 +108,15 @@ The complete list of rules, as of room version 3, is as follows:
than the `sender`'s power level, allow.
3. Otherwise, reject.
6. Otherwise, the membership is unknown. Reject.
7. If the `sender`'s current membership state is not `join`, reject.
8. If type is `m.room.third_party_invite`:
5. If the `sender`'s current membership state is not `join`, reject.
6. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
9. If the event type's *required power level* is greater than the
7. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
10. If the event has a `state_key` that starts with an `@` and does not
8. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
11. If type is `m.room.power_levels`:
9. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
Expand All @@ -137,7 +140,7 @@ The complete list of rules, as of room version 3, is as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
12. Otherwise, allow.
10. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
35 changes: 19 additions & 16 deletions content/rooms/fragments/v8-auth-rules.md
View file
Open in desktop
Expand Up @@ -34,18 +34,21 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
the create event, reject.
5. If type is `m.room.member`:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
3. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `content` has a `join_authorised_via_users_server`
key:
Expand Down Expand Up @@ -119,15 +122,15 @@ The rules are as follows:
or `join`, allow.
4. Otherwise, reject.
8. Otherwise, the membership is unknown. Reject.
6. If the `sender`'s current membership state is not `join`, reject.
7. If type is `m.room.third_party_invite`:
4. If the `sender`'s current membership state is not `join`, reject.
5. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
8. If the event type's *required power level* is greater than the
6. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
9. If the event has a `state_key` that starts with an `@` and does not
7. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
10. If type is `m.room.power_levels`:
8. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
Expand All @@ -151,7 +154,7 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
11. Otherwise, allow.
9. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
35 changes: 19 additions & 16 deletions content/rooms/v10.md
View file
Open in desktop
Expand Up @@ -106,18 +106,21 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
the create event, reject.
5. If type is `m.room.member`:
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
3. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `content` has a `join_authorised_via_users_server`
key:
Expand Down Expand Up @@ -194,15 +197,15 @@ The rules are as follows:
or `join`, allow.
4. Otherwise, reject.
8. Otherwise, the membership is unknown. Reject.
6. If the `sender`'s current membership state is not `join`, reject.
7. If type is `m.room.third_party_invite`:
4. If the `sender`'s current membership state is not `join`, reject.
5. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
8. If the event type's *required power level* is greater than the
6. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
9. If the event has a `state_key` that starts with an `@` and does not
7. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
10. If type is `m.room.power_levels`:
8. If type is `m.room.power_levels`:
1. {{< added-in this="true" >}}
If any of the keys `users_default`, `events_default`, `state_default`,
`ban`, `redact`, `kick`, or `invite` in `content` are present and
Expand Down Expand Up @@ -233,7 +236,7 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
11. Otherwise, allow.
9. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down