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.

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

Checks on PDUs is ambiguous when it refers to "the state at an event" #1069

Closed
DMRobertson opened this issue May 18, 2022 · 1 comment · Fixed by #1070
Closed

Checks on PDUs is ambiguous when it refers to "the state at an event" #1069

DMRobertson opened this issue May 18, 2022 · 1 comment · Fixed by #1070
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@DMRobertson
Copy link
Contributor

Link to problem area: https://spec.matrix.org/v1.2/server-server-api/#checks-performed-on-receipt-of-a-pdu

Whenever a server receives an event from a remote server, the receiving server must ensure that the event:
- [...]
- 5. Passes authorization rules based on the state at the event, otherwise it is rejected.

Emphasis mine.

Issue. The bolded phrase is ambiguous. It presumably means "the state before the event". Here's an example to justify this.


Alice is a moderator in a room with power level 70. She wishes to transfer some of her moderator power to Bob, currently power level 50, and demote herself. To do so, Alice creates an m.room.power_levels event which sets her power level to 60 and Bob's power level to 65.

As part of the checks on a PDU, incoming servers must verify that this event

  1. Passes authorization rules based on the state at the event, otherwise it is rejected.

When doing so, servers reach auth rules 9.4 which says:

For each entry being added, changed or removed in both the events, users, and notifications keys:
1. If the current value is higher than the sender’s current power level, reject.
2. If the new value is higher than the sender’s current power level, reject.

The "current power level" is not defined. I think the intent is that auth rules are always evaluated against a particular state map S, and in this case S is *the state at the event. (It's not fully clear if this is the case: the iterative auth checks algorithm talks about filling in missing bits of state by consulting the state at auth events.)

If S were the state after the incoming event, then Alice's current power level would be 60. She would therefore be unable to raise Bob's power level to 65. But this isn't sensible: Alice is fully entitled to make both power level changes when she creates the new power level event. That's reflected in the state before the event, where Alice has power level 70.

@DMRobertson DMRobertson added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label May 18, 2022
@richvdh
Copy link
Member

richvdh commented May 23, 2022

related: #697

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants