Element-web: Can set power levels of users not in the room

[chutten]

Description

While trying to /op our moderator, we accidentally used /op moderator:matrix.org instead of /op moderator:mozilla.org. There is no moderator:matrix.org in the channel, but it was successfully granted the powers of moderation anyway. (or at least the status message confirmed as much)

I worry typing mistakes like these could result in powers being granted to user accounts that could then later be created or joined. Sortof an identity fraud attack.

Steps to reproduce

• As admin, run /op moderator:matrix.org

Actual: Status message appears saying the user was granted powers.

Expected: Command failure and no powers being granted _in absentia_.

Logs being sent: no

Version information

• Platform: web

For the web app:

• Browser: Firefox beta 74
• OS: Windows
• URL: chat.mozilla.org

[t3chguy]

This is intentional with how permissions work and are held between leaving and rejoining a room. You should perhaphs use the graphical approach to permissions management where you invite a user then select them in right panel and promote them there instead of using commands which accept your input as gospel.

[chutten]

Given the omnipresence of the command input (and it being overloaded as also being the message input) I still worry about this as an attack angle. If it's designed to be this powerful, should we make it harder to find?

On the other hand, the risk is narrow (room-present members might be tricked into elevating others to at most their own level), so maybe this is just alarmism coupled with a usability nit.

Maybe the first time you run a command Riot should "This isn't a message, this is a command. It does X. Do you want to turn on commands from the message input and then perform X? Y/N" or limit the initial set of available commands to ones with lower downsides (join, msg, rainbow, shrug) and put the rest in devtools?

(( This is now getting into feature territory instead of bug ))

[turt2live]

ooi, was the command entered without the @? If so, we should probably have at least given a dialog about invalid formats instead of pretending the user ID is correct.

[chutten]

@dexterp37 was the one who entered the commands, maybe he remembers.

[Dexterp37]

ooi, was the command entered without the @? If so, we should probably have at least given a dialog about invalid formats instead of pretending the user ID is correct.

The command was /op @moderator:matrix.org, with the @

[Half-Shot]

This feels like it's in the same vein as inviting users who may not exist. We should warn (on first time?), but not disable entirely.

[nadonomy]

To frame the problem— we should expect most users to use the UI to configure admins & moderators, where I don't think it's a common goal for users to manage users who aren't in the room yet. As far as the UI is concerned, letting users have separate models of "which users are in this room?" & "which room members can I manage?" is the simplest.

From there— for users typing in /op commands I would err on the side of caution, based on the following:

• If we show an error or warning, there's no guarantee it'll be read, some users might just blindly re-op the person they wanted and go on with their day
• If we op a user absent from the room, we then have the problem of figuring out how to expose them— we'd probably want to do it persistently, so member list? which is problematic (it's a hard thing to explain, we could lump them with invited but they're not invited, and prompting users to invite someone in a typo could be useful for some people, but that isn't a core concern we should optimise for)

Overall, it just makes for a complicated model for everyone— so I'd advocate for us to just tell users when they try to /op someone not in the room so they never accidentally give away permissions, and let them fill in the blanks (i.e. invite the right person first) from there.

That comes at the expense of not being able to set ops before inviting people (rare), but I think it's the right trade off to make.