Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-04 18:54:09 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Many clarifications.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-04 08:52:35 -04:00 committed by Richard van der Hoff
parent 084e6225c5
commit 31cdf835b8
1 changed files with 29 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

59
proposals/3083-restricted-rooms.md
View file

@ -59,7 +59,7 @@ of the necessary spaces). In this case the homeserver should reject the join,
the requesting server may wish to attempt to join via other homeservers. the requesting server may wish to attempt to join via other homeservers.
Unlike the `invite` join rule, confirmation that the `allow` rules were properly Unlike the `invite` join rule, confirmation that the `allow` rules were properly
checked cannot be enforced over federation by event authorization, so servers in checked cannot be enforced over federation by event authorisation, so servers in
the room are trusted not to allow invalid users to join.<sup id="a3">[3](#f3)</sup> the room are trusted not to allow invalid users to join.<sup id="a3">[3](#f3)</sup>
## Summary of the behaviour of join rules ## Summary of the behaviour of join rules
@ -72,10 +72,10 @@ between `public`, `invite`, and `restricted`.
* `invite`: only people with membership `invite` can join, as today. * `invite`: only people with membership `invite` can join, as today.
* `knock`: the same as `invite`, except anyone can knock, subject to `ban` and * `knock`: the same as `invite`, except anyone can knock, subject to `ban` and
`server_acls`. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). `server_acls`. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403).
* `private`: This is reserved and not implemented. * `private`: This is reserved, but unspecified.
* `restricted`: the same as `public` from the perspective of the auth rules, but * `restricted`: the same as `public` from the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules),
with the additional caveat that servers are expected to check the `allow` rules but with the additional caveat that servers are expected to check the `allow`
before generating a `join` event (whether for a local or a remote user). rules before generating a `join` event (whether for a local or a remote user).
## Security considerations ## Security considerations
@ -89,36 +89,31 @@ joining spurious users into your rooms, then:
## Unstable prefix ## Unstable prefix
The `restricted` join rule will be included in a future room version to ensure The `restricted` join rule will be included in a future room version to allow
that servers and clients opt-into the new functionality. servers and clients to opt-into the new functionality.
During development it is expected that an unstable room version of During development, an unstable room version of `org.matrix.msc3083` will be used.
`org.matrix.msc3083` is used. Since the room version namespaces the behaviour, Since the room version namespaces the behaviour, the `allow` key and the
the `allow` key and the `restricted` value do not need unstable prefixes. `restricted` value do not need unstable prefixes.
## History / Rationale ## Alternatives
Note that this replaces the second half of an older version of It may seem that just having the `allow` key with `public` join rules is enough
[MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962). (as originally suggested in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962)),
It may seem that just having the `allow` key with `public` join rules is enough,
as suggested in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962),
but there are concerns that having a `public` join rule that is restricted may but there are concerns that having a `public` join rule that is restricted may
cause issues if an implementation does not understand the semantics of the `allow` cause issues if an implementation has not been updated to understand the semantics
keyword. Using an `allow` key with `invite` join rules also does not make sense as of the `allow` keyword. This could be solved by introducing a new room version,
from the perspective of the auth rules, this is akin to `public` (since the checking but in that case it seems clearer to introduce the `restricted` join rule, as
of whether a member is in the space is done during the call to `/join` described above.
or `/make_join` / `/send_join`).
The above concerns about an implementation not understanding the semantics of `allow` Using an `allow` key with `invite` join rules to broaden who can join was rejected
could be solved by introducing a new room version, but if this is done it seems clearer as an option since it requires weakening the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules).
to just introduce a a new join rule - `restricted` - as described above. From the perspective of the auth rules, the `restricted` join rule is identical
to `public` (since the checking of whether a member is in the space is done during
the call to `/join` or `/make_join` / `/send_join` regardless).
## Future extensions ## Future extensions
Potential future extensions which should not be designed out include, but are not
included in this MSC.
### Checking space membership over federation ### Checking space membership over federation
If a server is not in a space (and thus doesn't know the membership of a space) it If a server is not in a space (and thus doesn't know the membership of a space) it
@ -131,6 +126,9 @@ the peek server has significant power. For example, a poorly chosen peek
server could lie about the space membership and add an `@evil_user:example.org` server could lie about the space membership and add an `@evil_user:example.org`
to a space to gain membership to a room. to a space to gain membership to a room.
This MSC recommends rejecting the join in this case and allowing the requesting
homeserver to ask another homeserver.
### Kicking users out when they leave the allowed space ### Kicking users out when they leave the allowed space
In the above example, suppose `@bob:server.example` leaves `!users:example.org`: In the above example, suppose `@bob:server.example` leaves `!users:example.org`:
@ -167,7 +165,7 @@ It is possible that completely different state should be kept, or a different
### Inheriting join rules ### Inheriting join rules
If you make a parent space invite-only, should that (optionally?) cascade into If you make a parent space invite-only, should that (optionally?) cascade into
child rooms? Seems to have some of the same problems as inheriting power levels, child rooms? This would have some of the same problems as inheriting power levels,
as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962). as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
## Footnotes ## Footnotes
@ -176,7 +174,8 @@ as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
of the '#catlovers' space" is less useful since: of the '#catlovers' space" is less useful since:
1. Users in the banned space could simply leave it at any time 1. Users in the banned space could simply leave it at any time
2. This functionality is already somewhat provided by [Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1) 2. This functionality is already partially provided by
[Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1)
<a id="f2"/>[2]: Note that there is nothing stopping users sending and <a id="f2"/>[2]: Note that there is nothing stopping users sending and
receiving invites in `public` rooms today, and they work as you might expect. receiving invites in `public` rooms today, and they work as you might expect.
@ -184,7 +183,7 @@ The only difference is that you are not *required* to hold an invite when
joining the room. [↩](#a2) joining the room. [↩](#a2)
<a id="f3"/>[3]: This is a marginal decrease in security from the current <a id="f3"/>[3]: This is a marginal decrease in security from the current
situation. Currently, a misbehaving server can allow unauthorized users to join situation. Currently, a misbehaving server can allow unauthorised users to join
any room by first issuing an invite to that user. In theory that can be any room by first issuing an invite to that user. In theory that can be
prevented by raising the PL required to send an invite, but in practice that is prevented by raising the PL required to send an invite, but in practice that is
rarely done. [↩](#a3) rarely done. [↩](#a3)