Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Make AccessRules use the public rooms directory instead of checking a room's join rules on rule change #63

Merged
merged 17 commits into from
Sep 18, 2020

Conversation

anoadragon453
Copy link
Member

@anoadragon453 anoadragon453 commented Sep 11, 2020

Requires matrix-org/synapse#8292 over on mainline, which we plan to cherry-pick for now.

This PR makes use of the new public room directory features added to ThirdPartyEventRules by the above PR, by:

  1. Preventing publishing a room to the public rooms list if it has "unrestricted" access rule, during or after room creation.
  2. Preventing a room from changing its access rule to "unrestricted" if it is currently published in the public rooms directory.

When reviewing this PR, it's recommend to skip the first commit, as it's simply the port of the above PR.

@anoadragon453 anoadragon453 force-pushed the anoa/access_rules_public_rooms branch 2 times, most recently from 5107fd4 to 47b604e Compare September 11, 2020 13:48
@@ -76,8 +76,7 @@ def __init__(self, hs):
public_room_manager=PublicRoomsManager(hs),
)

@defer.inlineCallbacks
def check_event_allowed(self, event, context):
async def check_event_allowed(self, event, context):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We needed to async this method to eventually call the check on whether a room is public. Luckily this method is already awaited on everywhere!

synapse/handlers/room.py Outdated Show resolved Hide resolved
@anoadragon453 anoadragon453 force-pushed the anoa/access_rules_public_rooms branch 2 times, most recently from 8aca853 to 07d1dae Compare September 11, 2020 16:46
synapse/events/third_party_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Show resolved Hide resolved
synapse/events/third_party_rules.py Outdated Show resolved Hide resolved
synapse/events/third_party_rules.py Outdated Show resolved Hide resolved
changelog.d/63.misc Outdated Show resolved Hide resolved
changelog.d/8292.feature Outdated Show resolved Hide resolved
@anoadragon453
Copy link
Member Author

Thanks @babolivier. I've made the requested changes - the rest need to be made on the mainline PR as it deals with code coming from there.

Otherwise we just need to make a decision with @giomfo about the logic change discussion here: #63 (comment)

Even if we decide to change it back, doing so is trivial :)

@anoadragon453
Copy link
Member Author

anoadragon453 commented Sep 11, 2020

It was brought up that reverting the join_rules change in on_create_room is no different that simply creating a restricted room, and then setting its join rules to "public". This is intended behaviour, so we're going to continue removing that change in favour of using the public rooms list to manage visibility.

anoadragon453 added a commit to matrix-org/synapse that referenced this pull request Sep 14, 2020
@anoadragon453 anoadragon453 force-pushed the anoa/access_rules_public_rooms branch from 93f1b02 to c949c30 Compare September 14, 2020 18:31
@anoadragon453
Copy link
Member Author

I've rebased this PR on top of the latest mainline changes.

@anoadragon453 anoadragon453 force-pushed the anoa/access_rules_public_rooms branch from c949c30 to 507d3a2 Compare September 14, 2020 18:33
@babolivier
Copy link
Contributor

babolivier commented Sep 15, 2020

It was brought up that reverting the join_rules change in on_create_room is no different that simply creating a restricted room, and then setting its join rules to "public". This is intended behaviour, so we're going to continue removing that change in favour of using the public rooms list to manage visibility.

Currently it isn't possible to change the join rules of a room to public if the access rule isn't restricted, see here, here and here. This is valid regardless of whether these rules are set on room creation or afterwards, so the case you're describing doesn't exist (outside of this PR). Doing so also deviates from the spec of im.vector.room.access_rules.

FWIW I'm strongly opposed to this change as it would be a security regression. The point of the public room directory is to advertise rooms, and it isn't in any shape of form an authorisation feature (which is precisely what the join rules are). If we dropped the checks on join rules in favour of checking the visibility of the room in the public room directory, nothing could prevent e.g. someone making up their own directory, outside of Matrix, which would list rooms that any blacklisted server can join without an invite (which isn't possible currently but would be made possible by this PR).

@giomfo
Copy link
Member

giomfo commented Sep 15, 2020

@babolivier I understood your point of view, I will check again with DINUM if they are aware of this point that you named "security regression".
I don't think this is a "security regression", the actual room access will be still controlled by the im.vector.room.access_rules value.

I consider the sanity check on join_rule was introduced to limit the risk for an admin to give access to an exposed (=published) room to the users of the blacklisted servers without realising it. The DINUM request was already only for the rooms published in the room directory (which were the only rooms accessible by link).

Let's have a talk about this ;)

Note: I agree if the PR is merged, the following spec must be updated:
image

@giomfo
Copy link
Member

giomfo commented Sep 15, 2020

I got an interesting suggestion from DINUM:
"A user from a blacklisted server must have an invite to join a room even if the room is accessible by link"

This means an update about the "unrestricted" preset:
"Doesn't apply any restriction on who can join the room, but a user from a blacklisted server must have an invite to join the room (even if the join_rule is public)

@anoadragon453 anoadragon453 force-pushed the anoa/access_rules_public_rooms branch from afbe238 to e952eab Compare September 16, 2020 10:23
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
…ricted w invite

Also do some public rooms directory -> public room list wording fixes.
Copy link
Member

@giomfo giomfo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM (I checked mainly the new logic about the room access)
I let @babolivier review too

synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
Copy link
Contributor

@babolivier babolivier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of docs that can use a bit more polishing, otherwise lgtm 🎉

synapse/third_party_rules/access_rules.py Show resolved Hide resolved
tests/rest/client/test_room_access_rules.py Outdated Show resolved Hide resolved
synapse/third_party_rules/access_rules.py Outdated Show resolved Hide resolved
@anoadragon453 anoadragon453 merged commit 3fe1c84 into dinsic Sep 18, 2020
@anoadragon453 anoadragon453 deleted the anoa/access_rules_public_rooms branch September 18, 2020 10:30
anoadragon453 added a commit that referenced this pull request Oct 9, 2020
…oa/freeze_rooms

* 'dinsic' of github.com:matrix-org/synapse-dinsic:
  Only assert valid next_link params when provided (#65)
  Don't push if an user account has expired (#58)
  Swap method calls in RoomAccessTestCase.test_change_rules (#64)
  Make all rooms noisy by default (#60)
  Make AccessRules use the public rooms directory instead of checking a room's join rules on rule change (#63)
  Override the power levels defaults, enforce mod requirement for invites, admin requirements for unknown state events (#61)
  RoomAccessRules cleanup (#62)
  Add a config option for validating 'next_link' parameters against a domain whitelist (#8275)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants