Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users with insufficient power can issue broken 3PID invites to a room #1208

Closed
matrixbot opened this issue Mar 18, 2016 · 6 comments
Closed
Labels
P1 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Release-Blocker

Comments

@matrixbot
Copy link

Created by @ matthew:matrix.org.

An invite mail gets generated apparently, but the user then gets an error on trying to set the m.room.third_party_invite state event if they don't have enough permission. So the invite is broken

@dbkr
Copy link
Member

dbkr commented Mar 18, 2016

I'm about to mitigate this bug by preventing vector from trying to 3pid invite if the user is a guest (as part of #1101 ) but presumably this is a bug in synapse that should be fixed too.

@ara4n
Copy link
Member

ara4n commented Mar 18, 2016

this isn't just if the user's a guest, though, but if they lack power to set state events in general

@ara4n ara4n added ambiguous S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect P1 and removed ambiguous labels Mar 18, 2016
@ara4n ara4n added this to the v1 - Private Preview milestone Mar 18, 2016
@richvdh
Copy link
Member

richvdh commented Apr 13, 2016

What is the correct behaviour?

  1. special-case m.room.third_party_invite and allow users to add new ones if they have permission to send invites in general
  2. don't send the invite email (and reject the invite request) if the user's power level doesn't include the right to set m.room.third_party_invite state. As that currently stands, in practice it would mean that they need to be an admin, as allowing people to send such events also allows them to modify invites that other people have sent.
  3. we could add a new permission level specifically for sending 3pid invites, which would allow the sending of new m.room.third_party_invites but not the modification of others.

My preference is probably 1, but once we tweak the permission model like that, there's no going back. @ara4n, @erikjohnston ?

@ara4n
Copy link
Member

ara4n commented Apr 29, 2016

my preference is also 1. @erikjohnston?

@erikjohnston
Copy link
Member

I guess the first is the only realistic option.

@ara4n
Copy link
Member

ara4n commented Jun 1, 2016

PR hopefully specialcases appropriately. Shifting over to the PR to track progress.

@ara4n ara4n closed this as completed Jun 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Release-Blocker
Projects
None yet
Development

No branches or pull requests

5 participants