contentadmin differs to regular sysop permissions in this limited set, however if we go to the wiki, we see that in practice, there's a whole lot more of permissions that ain't present in the contentadmin user group. This is strange as $wgGroupPermissions['contentadmin'] = $wgGroupPermissions['sysop']; minus those excluded.
|operations/mediawiki-config||master||+5 -1||wikitech: Align 'contentadmin' and 'sysop' permissions|
According to this comparaison, non-intended missing permissions are:
- createaccount (well, it's on '*' already so I don't worry that much)
editinterface-like permissions are rightly excluded but these others I mention do not seem like they're explicitly excluded from config files so I wonder why they do not appear. Is it possible that because I cannot edit MediaWiki:Spam-blacklist I do not have spamblacklistlog permissions? On the other hand, massmessage does not seem to depend on MediaWiki restricted pages so it's not clear for me why it does not appear.
User rights explicitely removed from 'contentadmin' in CommonSettings.php:
- Edit other users' CSS files (editusercss)
- editrestrictedfield (this is apparently part of PageForms, which does not seem to be deployed to wikitech and hence should be removed)
- Edit the user interface (editinterface)
- Override the title or username blacklist (tboverride)
- View title blacklist log (titleblacklistlog)
- Override the spoofing checks (override-antispoof)
- Create new user accounts (createaccount)
@Krenair set these explicit removals back in c9f3ef6526c4 - maybe he knows what the reason was to keep some of these rights away from contentadmins (e.g. createaccount, override-antispoof, titleblacklistlog, tboverride).
Also, is "editusercss" and "edituserjs" actually dangerous? Of course "editinterface" is, as the MediaWiki: namespace has it's special role on wikitech, but these other rights are just for editing other users css/js, which doesn't share that special role (or does it?).
User shown for sysop (but not contentadmin) on Special:Version, but not explicitely removed in CommonSettings.php:
- Mass delete pages (nuke)
- Send a message to multiple users at once (massmessage)
- View the spam blacklist log (spamblacklistlog)
These are all from extensions that use the new extension registration and grant the respective right to 'sysop' from extension.json by default:
Iirc the default permissions (as set in extension.json) and $wgGroupPermissions (as set in LocalSettings.php) are merged after LocalSettings.php is evaluated, which means those rights are added to sysop after $wgGroupPermissions['contentadmin'] = $wgGroupPermissions['sysop'] is set, which is why they don't appear on contentadmin. @Legoktm might know whether this is really the issue and, if so, whether we should just add those rights to $wgGroupPermissions['contentadmin'] (workaround in config with three assignments) or look for a way to make extension registration work with $wgGroupPermissions['foo'] = $wgGroupPermissions['bar'];.
Would you dare to enlighten us, or is that knowledge somehow security-sensitive itself? :) I've searched for documentation on this on-wiki, but unfortunately I couldn't find anything specific.
Looking at the blacklist, I can easily guess why. I assume override-antispoof is for the same reason, though I haven't figured out how titleblacklistlog would do any harm (as it just allows viewing the log).
I've uploaded a patch to add the permissions missing due to them being added in extension registration (nuke, massmessage, spamblacklistlog) and cleaning up the editrestrictedfield line as PageForms (formerly SemanticForms) has been undeployed from Wikitech. All other permissions are left as they are.
massmessage, nuke and spamblacklistlog are now available to contentadmin. The following rights remain as the difference between sysops and contentadmins and were not added as they are missing intentionally:
- editusercss (per comments above)
- edituserjs (per comments above)
- editinterface (per comments above)
- tboverride (per comments above)
- titleblacklistlog (probably as it's related to tboverride)
- override-antispoof (probably for the same reason as tboverride)
- createaccount (per Andrews comment back on https://gerrit.wikimedia.org/r/#/c/222776/ )