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

MSC3757: Restricting who can overwrite a state event #3757

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

andybalaam
Copy link
Contributor

@andybalaam andybalaam commented Mar 25, 2022

Rendered

Written by @ara4n , with contributions from @Johennes and @andybalaam .

@andybalaam andybalaam changed the title Restricting who can overwrite a state event MSC3757: Restricting who can overwrite a state event Mar 25, 2022
@turt2live turt2live added requires-room-version An idea which will require a bump in room version proposal-in-review proposal A matrix spec change proposal s2s Server-to-Server API (federation) client-server Client-Server API unassigned-room-version Remove this label when things get versioned. kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Mar 25, 2022
@gleachkr

This comment was marked as duplicate.

Copy link
Contributor

@ShadowJonathan ShadowJonathan left a comment

Choose a reason for hiding this comment

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

One nit, else this looks sound.

andybalaam and others added 5 commits March 31, 2022 11:44
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Travis Ralston <travisr@matrix.org>
@jplatte jplatte mentioned this pull request Apr 4, 2022
@ara4n
Copy link
Member

ara4n commented Feb 12, 2023

Does anyone actually object to this MSC? Its absence is currently screwing over my attempt to track multiple beacons via MSC3489 from a given user :(


None yet.

## Alternatives
Copy link
Member

Choose a reason for hiding this comment

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

String-based matching still feels like a bandaid solution for a larger problem. The problem statement is reasonable (beacons, calls, and integrations all want an ability to narrow power levels), however there are non-state events where it'd be worth having a similar access mechanism (namely for edits).

At the point where we're considering string-packing, a top level field on the event works just as well and is more extensible, capable, and presentable than a packed string. It can be populated with query parameters to the PUT /state or PUT /send calls, and servers are easily able to retrieve information from the event. Further, since we're modifying the auth rules to accomplish this, there is no material difference to the implementation effort of the proposal itself.

Copy link

Choose a reason for hiding this comment

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

I am wondering if a top level field implies that state_key and access mechanism are independent.

If this is what is proposed I have the concern that this would allow blocking of state keys by not allowing to write to them anymore. (I think I saw this being brought up somewhere else as well. cannot find it right now)

But the concept of merging key + access level makes a lot of sense to me since it would behave more like a namespace than an add-on permission system. And I think the idea of namespaces (kind of like inverse domains where each user owns the domain starting with their username) is a very good fit for a key value based state like the room state.

Copy link
Contributor Author

@andybalaam andybalaam Jun 14, 2024

Choose a reason for hiding this comment

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

(edited out to avoid confusion)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, the above was wrong - I was mixing this up with #3779 which I think replaces this, and which I prefer.

@toger5
Copy link

toger5 commented May 7, 2024

I would like to add another solution.
State keys could be of type: string | string[]
Where state_key: string = "hello" is a shortcut for state_key: string[] = ["hello"].
Our access rule would become:

If the events the state_key contains a user id that does not match the sender, reject.

  • unless the sender's powerlevel is greater than the event type's required power level.

Treating state keys as a path also mirrors a nice mental model to split bigger state events into objects build up by multiple state events so we would not need a state change request. Also I am worried that a state subkey (like in MSC3760 could quickly get its own rules like: "only allow to chnage by the device with that deviceId" and we might need a state-sub-sub-key. Making the state key a path solves this. It would be trivial to add rules like [$userId, $deviceId, something] can only be edited by the defined device...

Here is a visualization of how the state path can be thought of as a path to a subsection of an object.

This array of stat events

[
{
 "state_key": "a",
 "content": {
  "my_property": "a"
 }
},

{
 "state_key": ["b", "a"],
 "content":{"test":1}
},

{
 "state_key": ["b","@myId:domain.com"],
 "content": {
   "data": "data",
   "note": "this object owned by the user: @myId:domain.com"
  }
},

{
 "state_key": ["b", "@myId:domain.com", "subElement"],
 "content": {
   "note": "also owned by: @myId:domain.com",
   "editProps": "but can be edited independently as a sub state object"
  }
}
]

Can be thought of/parsed as this room state object.

{
 "a": {
  "content":{"my_property": "a"}
 },
 "b": {
  "@myId:domain.com":{
   "content": {"other": "data"},
   "subElement"{
    "content":{
        "note": "also owned by: @myId:domain.com",
        "editProps": "but can be edited independently as a sub state object"
    }
   }
  },
  "a":{
   "content":{"test":1}
  }
 }
}

A concrete example for b could be:
["ephemeralLocations",$userId], ["presistentLocations",$userId]
Or b could be the user Id and we inside each user we have a list of devices for the call member event example

One can think of the state event type as the first element in the array/path.
state_property_path = [$state_event_type] + state_key
It still makes sense however, that the type is its own field since we always need a type. Which is better then requireing the key array to be of min length one.

Additinally the state_key = "" would be equivalent to state_key=[] which makes much more sense thinking of it as a property path: path = [$state_event_type] + state_key = [$state_event_type]

@richvdh
Copy link
Member

richvdh commented May 21, 2024

I'm not necessarily against this proposal per-se, but I remain very worried that we have no practical means of deleting state from a room, and it seems like most applications that would make use of this proposal would tend towards large amounts of state being added to a room which then has to hang around forever.

(#3901 is a proposal to deal with deleting state, but it needs implementation work)

@AndrewFerr
Copy link
Member

I remain very worried that we have no practical means of deleting state from a room, and it seems like most applications that would make use of this proposal would tend towards large amounts of state being added to a room which then has to hang around forever.

What could mitigate this somewhat is #4140 working together with #3901 to allow for state events that expire into obsoleted events. That would allow for applications of this MSC to set state that would eventually be marked for cleanup/deletion.


becomes:

> If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the event type's *required power level*.
Copy link
Member

Choose a reason for hiding this comment

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

To overwrite another user's state event, must your power level exceed the event type's PL, or the PL of the user who owns the event?

i.e. should this be reworded to the following:

Suggested change
> If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the event type's *required power level*.
> If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the powerlevel of the user whose matrix ID is the prefix of the `state_key`.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To overwrite another user's state event, must your power level exceed the event type's PL, or the PL of the user who owns the event?

I was thinking of the event type's power level i.e. we're not changing anything here except expanding the existing exception where a user can create a state event beyond their power level if they use a specific state key.

Could the wording be improved to clarify this?

Copy link
Member

Choose a reason for hiding this comment

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

a user can create a state event beyond their power level if they use a specific state key

This isn't mentioned anywhere, at least not explicitly. If the only intended change to the auth rules is the change to step 8, then the preceding step still says to reject if the sender's PL is less than the event type’s required power level.

For the exception to hold, step 7 could simply be removed, meaning the PL restriction would be applied by the proposed change to rule 8.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, no -- that would remove PL restrictions for non-state events.

How about replacing steps 7 and 8 with this:

  • If the event type’s required power level is greater than the sender’s power level, and the event does not have a state_key matching the sender optionally followed by a substring prefixed with _, reject.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hang on, I was getting confused with #3779 - sorry for the confusion!

I think this MSC restricts who can overwrite certain state events, and I agree that the wording as it is now doesn't make sense, because it actually allows everyone to overwrite, because we won't reach rule 8 without first passing rule 7 which already checks power level.

I think I just prefer #3779 over this one, and if I understand right, we don't need both.

@andybalaam
Copy link
Contributor Author

I would like to add another solution. State keys could be of type: string | string[] Where state_key: string = "hello" is a shortcut for state_key: string[] = ["hello"]. Our access rule would become:

I would buy into this if others felt it was better. I think it would make @turt2live happier?

I feel a little concerned about the ambiguity of whether "" = [""] or [] but that is a minor detail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet