Auth rules: behaviour unclear if no power level event is cited as an auth event

[DMRobertson]

Link to problem area: https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules and also https://spec.matrix.org/v1.2/client-server-api/#mroompower_levels

Issue
The auth rules say:

INFO: Power levels are inferred from defaults when not explicitly supplied. For example, mentions of the sender’s power level can also refer to the default power level for users in the room.

I think this is talking about the situation where the auth rules need to lookup the power level of @alice:alice.com from some state map, but Alice does not have an explicit power level.

What happens if the event E under consideration does not cite an auth event of type m.room.power_levels?

Options that spring to mind:

1. Reject E outright (making an exception for the initial bit of room state added after the room is created).
2. Look for a power levels event in the auth chain of E, rather than just E itself. (But perhaps this need not exist---what then?)
3. Use the default power levels given in the C-S spec as the intended power levels when there is no such power level event in the room.

   • If this is the case, the wording in the C-S spec is unhelpful. It reads

     if the room contains no m.room.power_levels event [...]

     but it's possible that the room contains an m.room.power_levels event somewhere else in the DAG---it's just that one hasn't been cited as an auth_event here.

The wording of the INFO box in the auth rules makes me think option 3 is intended. Can anyone confirm or refute?

[timokoesters]

If there is no power level event, ruma uses the default power levels event, so your option 3.

https://github.com/ruma/ruma/blob/e1ebff00470e71256336872dbfebfae53332c622/crates/ruma-state-res/src/event_auth.rs#L457-L460

[turt2live]

The language is from a previous time, so there's some wording differences compared to modern spec, but this is what the spec says: https://spec.matrix.org/v1.2/server-server-api/#auth-events-selection

The auth_events field of a PDU identifies the set of events which give the sender permission to send the event. The auth_events for the m.room.create event in a room is empty; for other events, it should be the following subset of the room state:

• The m.room.create event.
• The current m.room.power_levels event, if any.
• The sender’s current m.room.member event, if any.
• If type is m.room.member:
  • [...]

as mentioned, this is historical spec so the language is a bit different: it sounds like it's trying to say that the events are required if they exist, otherwise since there's no way to reference something that doesn't exist they can be excluded. Thus, by extension, it should be rejected under the current spec's language to have an event without a power levels reference (if a power levels event existed).

However, that doesn't mean the spec is correct: we should see what Synapse has (always) done for v1 rooms specifically, then carry that as a clarification to the spec.

Note: the spec uses the word "should" in the auth events selection. This is also historical spec and would be replaced with "must" or similar if rewritten.

[DMRobertson]

Thus, by extension, it should be rejected under the current spec's language to have an event without a power levels reference (if a power levels event existed).

It's not clear what it means for a power level event to exist! This is what I'm driving at in the subitem under point 3 in the original post.

There's an implicit suggestion in the checks on an event that the auth rules are evaluated with respect some ambient state map:

4. Passes authorization rules based on the event’s auth events, otherwise it is rejected.
5. Passes authorization rules based on the state at the event, otherwise it is rejected.
6. Passes authorization rules based on the current state of the room, otherwise it is “soft failed”.

But the details aren't explicit.

[turt2live]

The historical spec (which is mostly the s2s stuff) is very much figuring out the implied constraints of the system, unfortunately.

I suppose the general case would be that since auth events define permission to send the event, you could argue that the event is being sent deliberately at a different point in the DAG. Referencing a "current" membership event (which in turn references "current" power levels) but not referencing those power levels yourself would be pretty weird.

[DMRobertson]

Referencing a "current" membership event (which in turn references "current" power levels) but not referencing those power levels yourself would be pretty weird.

Again, it is hard to assign meaning to this without specifying what "current" means. With that said:

It is perfectly possible for an event E to cite an auth event which is not an ancestor of E (ancestor following prev_event edges only). I agree that it is weird, but it something that the protocol as a whole must anticipate. Indeed, that's why the auth rules are checked three times against different collections of state.

[turt2live]

Current is always whatever the server has resolved as current state, ftr.

[DMRobertson]

Current is always whatever the server has resolved as current state, ftr.

While I think this is generally true, I don't think it's the case for the auth rules as written today. I'm hoping to get round to writing this up more precisely in the near future.