From ce2132225a0532afd2c1b5dce0c40fd00badbf57 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Tue, 4 Apr 2023 18:56:21 -0500 Subject: [PATCH 1/4] Add proposal for raising a power level above current limits --- proposals/0000-increase-power-level.md | 111 +++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 proposals/0000-increase-power-level.md diff --git a/proposals/0000-increase-power-level.md b/proposals/0000-increase-power-level.md new file mode 100644 index 00000000000..695ab9472e7 --- /dev/null +++ b/proposals/0000-increase-power-level.md @@ -0,0 +1,111 @@ +# MSC0000: Power level up! Taking the room to new heights + +Once a room is created, the highest power level is set in stone. Even if you're the only +admin in the room, if you try to raise your own power level above the initial `100`, it +just throws a `403 Forbidden` error: + +`PUT /_matrix/client/r0/rooms/{roomId}/state/m.room.power_levels` -> `403 Forbidden` +```json +{ + "errcode": "M_FORBIDDEN", + "error": "You don't have permission to add ops level greater than your own" +} +``` + +This is dictated by the [authorization rules (auth +rules)](https://spec.matrix.org/v1.5/rooms/v10/#authorization-rules) around +`m.room.power_levels` in a room: + +> 9. If type is `m.room.power_levels`: +> [...] +> +> 8. For each entry being changed in, or removed from, the `users` property, other than the `sender`’s own entry: +> 1. If the current value is greater than or equal to the `sender`’s current power level, reject. +> 9. For each entry being added to, or changed in, the `users` property: +> 1. If the new value is greater than the `sender`’s current power level, reject. + +It's possible to have power levels greater than the default `100` (Admin) power level +but this has to be specified at the time of room creation. + +Not being able to adjust the max power level of `users` after the fact means that any +mistake is baked into the room forever and requires a room upgrade to rectify the +situation. Sometimes, more flexibility is needed in the power level ranges and this only +becomes obvious with hindsight. + +For example with the [Gitter +migration](https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/), we +synced all Gitter room admins over as users with a power level of `90` and set the power +level to do any action at `90` so the bridge bot user could maintain a higher power +level than the rest of the users while giving the room admins autonomy over everything. +Then later after the migration, we wanted to clean up the power levels and grant room +admins the true `100` power level to avoid clients labeling `90` as a "Moderator" +instead of "Admin". But discovered this was impossible to get right because we couldn't +raise the power level of the bridge bot above `100` to still maintain a higher power +level. This condundrum is tracked by https://gitlab.com/gitterHQ/gitter.im/-/issues/4 + +Something like [MSC3915: Owner power +level](https://github.com/matrix-org/matrix-spec-proposals/pull/3915) could help in a +situation like this to formalize the position of owner but doesn't help with the +flexibility of an existing room. For example, imagine this MSC lands before MSC3915, it +would be nice to just upgrade your room power levels to reflect the new owners role. And +going beyond MSC3915, it can be useful to set a user/bot above `150` at a later date. +Imagine wanting a central company bot to maintain control of every room at power level +`200`. It would be nice to just update your room power levels to achieve this than have +to upgrade every room. + + + +## Proposal + +This MSC proposes updating the room event auth rules to allow for raising the `sender`'s +own `users` power level above the current max power level as long as you update all +others at the same level to the new max level. + +This means that if you're a solo admin in the room, you can arbitrarily raise your own +power level however you want. + +If there are multiple admins in the room, then you must raise all other admins to the +new max power level. + +Propsed new auth rule language: + +> 9. If type is `m.room.power_levels`: +> [...] +> +> 8. For each entry being removed from the `users` property, other than the `sender`’s own entry: +> 1. If the current value is greater than or equal to the `sender`’s current power level, reject. +> 9. For each entry being added to, or changed in, the `users` property: +> 1. If the new value is greater than the `sender`’s current power level and the `sender` *doesn't have* the highest power level in the room, reject. +> 1. If the new value is greater than the `sender`’s current power level, the `sender` *has* the highest power level in the room, but doesn't raise everyone else with the current highest power level to the new value, reject. + +Because this MSC changes the authorization rules of a room, it requires a new room +version to ensure all participating servers are authorizing events and state +consistently. + + +## Potential issues + +*None surmised so far* + + +## Alternatives + +Room upgrades allow for creating a new room where you can initially specify +`m.room.power_levels` as desired. There is nothing restricting the integer range that +`users` field of `m.room.power_levels` so all of the same end results can be achieved +this way. This has all of the flexibility downsides mentioned for existing rooms in the +intro/context paragraphs above though. + + +## Security considerations + +Changes to auth rules requires careful consideration of how things interact and the +language should be explicit in what's allowed/rejected. Please review the proposed +changes for holes in the logic. + + +## Unstable room version + +While this feature is in development, the proposed behavior can be trialed with the +`org.matrix.mscXXXX` unstable room version and `org.matrix.mscXXXXv2`, etc as we develop +and iterate along the way. From 32b7bcb22da4285d42012c1d67936a9c206ecb77 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Tue, 4 Apr 2023 18:59:42 -0500 Subject: [PATCH 2/4] Use MSC number --- ...0-increase-power-level.md => 3991-increase-power-level.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{0000-increase-power-level.md => 3991-increase-power-level.md} (97%) diff --git a/proposals/0000-increase-power-level.md b/proposals/3991-increase-power-level.md similarity index 97% rename from proposals/0000-increase-power-level.md rename to proposals/3991-increase-power-level.md index 695ab9472e7..24bc87670fd 100644 --- a/proposals/0000-increase-power-level.md +++ b/proposals/3991-increase-power-level.md @@ -1,4 +1,4 @@ -# MSC0000: Power level up! Taking the room to new heights +# MSC3991: Power level up! Taking the room to new heights Once a room is created, the highest power level is set in stone. Even if you're the only admin in the room, if you try to raise your own power level above the initial `100`, it @@ -107,5 +107,5 @@ changes for holes in the logic. ## Unstable room version While this feature is in development, the proposed behavior can be trialed with the -`org.matrix.mscXXXX` unstable room version and `org.matrix.mscXXXXv2`, etc as we develop +`org.matrix.msc3991` unstable room version and `org.matrix.msc3991v2`, etc as we develop and iterate along the way. From dec22ac804c469e2a562c38acc86183f3ae627fd Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Wed, 5 Apr 2023 17:22:56 -0500 Subject: [PATCH 3/4] Note alternative for Gitter specific case about specing power level labels See https://github.com/matrix-org/matrix-spec-proposals/pull/3991#discussion_r1158781438 --- proposals/3991-increase-power-level.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/proposals/3991-increase-power-level.md b/proposals/3991-increase-power-level.md index 24bc87670fd..b4a469d33f2 100644 --- a/proposals/3991-increase-power-level.md +++ b/proposals/3991-increase-power-level.md @@ -54,7 +54,6 @@ Imagine wanting a central company bot to maintain control of every room at power to upgrade every room. - ## Proposal This MSC proposes updating the room event auth rules to allow for raising the `sender`'s @@ -93,8 +92,22 @@ consistently. Room upgrades allow for creating a new room where you can initially specify `m.room.power_levels` as desired. There is nothing restricting the integer range that `users` field of `m.room.power_levels` so all of the same end results can be achieved -this way. This has all of the flexibility downsides mentioned for existing rooms in the -intro/context paragraphs above though. +this way. But this has all of the flexibility downsides mentioned for existing rooms in +the intro/context paragraphs above though. + +--- + +As an [alternative that could solve the Gitter specific +case](https://gitlab.com/gitterHQ/gitter.im/-/issues/4) where a user with a power level +of `90` appears as "Moderator" when it actually functions as an admin role; this could +be solved by spec'ing out how to figure out what is the admin PL and what is the +moderator PL. Hardcoding random integers to labels just doesn't work well. For example, +with the [Nheko](https://github.com/Nheko-Reborn/nheko) client, it considers people with +the permission to change powerlevels to be admins and users with redaction permissions +are moderators. Or maybe something more flexible like [MSC3949: Power Level +Tags](https://github.com/matrix-org/matrix-spec-proposals/pull/3949). + +This MSC does make sense on top of those kind of changes in any case though. ## Security considerations From d3e8aa670f5a896608f4b74a409d2cb9faccdb72 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Tue, 11 Apr 2023 13:12:06 -0500 Subject: [PATCH 4/4] Better wording on Gitter alternative --- proposals/3991-increase-power-level.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/3991-increase-power-level.md b/proposals/3991-increase-power-level.md index b4a469d33f2..2bd18ba5d37 100644 --- a/proposals/3991-increase-power-level.md +++ b/proposals/3991-increase-power-level.md @@ -97,14 +97,14 @@ the intro/context paragraphs above though. --- -As an [alternative that could solve the Gitter specific +As an alternative that could solve the [Gitter specific case](https://gitlab.com/gitterHQ/gitter.im/-/issues/4) where a user with a power level of `90` appears as "Moderator" when it actually functions as an admin role; this could be solved by spec'ing out how to figure out what is the admin PL and what is the moderator PL. Hardcoding random integers to labels just doesn't work well. For example, with the [Nheko](https://github.com/Nheko-Reborn/nheko) client, it considers people with -the permission to change powerlevels to be admins and users with redaction permissions -are moderators. Or maybe something more flexible like [MSC3949: Power Level +the permission to change power levels to be admins and users with redaction permissions +as moderators. Or maybe something more flexible like [MSC3949: Power Level Tags](https://github.com/matrix-org/matrix-spec-proposals/pull/3949). This MSC does make sense on top of those kind of changes in any case though.