Server access control lists can "ban" users with higher power levels #554
Labels
A-Client-Server
Issues affecting the CS API
wart
A point where the protocol is inconsistent or inelegant
The server access control lists feature for a room is intended to ban an entire homeserver from participating in a room because its operator is using it for malicious activities, such as spamming. This is implemented via the
m.room.server_acl
event. Users that are residing on a homeserver that has been banned from participating in a room can no longer send events but will still receive events. This makes the server access control lists similar to a ban, albeit a banned user also no longer receives events.The
m.room.server_acl
event is a regular state event and is not listed separately in them.room.power_levels
event, so the emission ofm.room.server_acl
will require a power level of 50 in most rooms. It is also a principle in the design philosophy of Matrix that administrative actions against users require having a higher power level than the targeted user or permission. So, Alice(50) cannot kick Bob(100). The other way around is very well possible.The
m.room.server_acl
does not have any such restrictions. Assuming Alice(50) resides on alice.org and Bob(100) is on bob.org, then Alice can add bob.org to the deny list and effectively remove him from participation in room.Yes, this requires an elevated power level in most rooms (assuming a rather standard version of
m.room.power_levels
) and yes, this is currently a design choice that can be made. I just want to spark a discussion whether additional checks should be placed on them.room.server_acl
event to be, in my opinion, more consistent with the rest of the access control model.The text was updated successfully, but these errors were encountered: