Page MenuHomePhabricator

Introduce and document a minimum rights hierarchy
Open, MediumPublic



There seems to be an undocumented and inconsistent hierarchy of rights. For example, if I cannot view a page, I cannot edit it. But: if I can't edit, can I still move? In particular, the API has no concept of a hierarchy of rights. This leads to potential security issues in read protected MediaWikis.

Who would benefit

Extension developers and MediaWiki maintainers will have a more clear cut security model.

Proposed solution

We should add a minimum hierarchy in our rights, such as read > edit > other actions, similar to the way we have a hierarchy in the user groups: * > user > other groups. If one cannot read, they cannot do anything else. If one cannot edit, they cannot do any other modifications. I know this is too simplistic, so we need to sketch out a proper hierarchy. The hierarchy should also be documented.

Event Timeline

Just to be clear, this task is asking both for code changes (adding a proper rights hierarchy as part of the user permissions system in MW core) and documentation (documenting this new hierarchy system on It's not 100% clear that code changes are being asked for here.

There isn't really a hierarchy in user groups either. It only seems that way because '*' means "everyone" and 'user' means "all logged-in users", so it's very hard to have a user in any other group without also being in those two.

If one cannot read, they cannot do anything else.

Looking at the action API in core, someone without the 'read' right can still potentially log in, log out, create accounts, fetch CSRF tokens, fetch RSD information, submit CSP reports, access the help, access paraminfo (which is basically machine-readable help), and query AuthManager information. Some of those require rights other than 'read', e.g. "create accounts" needs the ability to create accounts, and "log in" might need the ability to auto-create accounts.

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

@TTO, yes I propose a code change as well as documentation. If you'd ask me for priorisation, I'd go for documentation first. I am pretty sure we will find peculiar dependencies during documentation, which I then propose to be fixed.
In addition, I propose to have a set of very basic rights which are the basis for other rights. Tuning such an extensive set of 80+ rights as we see it in MediaWiki is painful and failure prone. If, for example, I can rely on the fact that taking away read rights also completely takes away edit rights, or taking away the edit right would take away all modification rights, this would simplify the set up a lot, reduce accidential misconfigurations and make MediaWiki safer in the end.

Some related notes regarding rights hierarchy: