Description
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
- 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.