Page MenuHomePhabricator

Inconsistent user permissions for users who were recently added to a new group
Open, Needs TriagePublic

Description

Permissions on deployment-prep enwiki seem to be inconsistent between index.php and api.php. I made myself a bureaucrat via createAndPromote.php so I’d be able to make my colleagues sysops (for testing things):

lucaswerkmeister-wmde@deployment-deploy01:~$ mwscript createAndPromote.php enwiki 'Lucas Werkmeister (WMDE)' --force --custom-groups=bureaucrat  # make myself bureaucrat to make colleagues sysops
enwiki: Promoting User:Lucas Werkmeister (WMDE) into bureaucrat...
done.

Mentioned in SAL (#wikimedia-releng) [2020-01-31T11:47:05Z] <Lucas_WMDE> lucaswerkmeister-wmde@deployment-deploy01:~$ mwscript createAndPromote.php enwiki 'Lucas Werkmeister (WMDE)' --force --custom-groups=bureaucrat # make myself bureaucrat to make colleagues sysops

But Special:UserRights/Lucas Werkmeister (WMDE) doesn’t show the group:

Member of: Confirmed users, Administrators

Implicit member of: Autoconfirmed users

I ran the script again (with the --bureaucrat option, which I found in the --help, rather than --custom-groups=bureaucrat, just in case it made a difference), but it reported nothing to do:

lucaswerkmeister-wmde@deployment-deploy01:~$ mwscript createAndPromote.php enwiki 'Lucas Werkmeister (WMDE)' --force --bureaucrat  # make myself bureaucrat to make colleagues sysops
Account exists and nothing to do.

Special:UserRights/Michael Große (WMDE) showed that I was not allowed to edit their membership in the administrators group; however, I was able to sysop them via the API:

https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=userrights&format=json&user=Michael%20Gro%C3%9Fe%20(WMDE)&add=sysop&reason=allow%20administrative%20actions%20(protect%20pages%2C%20block%20users)%20to%20test%20Wikidata%20Bridge%20behavior%20in%20such%20situations&token=[expunged]

The resulting group membership change was logged, but Special:UserRights doesn’t show the group (even though it shows the log entry).

Screenshot_2020-01-31 User rights - Wikipedia, the free encyclopedia(1).png (729×1 px, 113 KB)

They are also able to perform administrative actions such as protecting a page, but only through the API – normal page views continue to look like those for unprivileged users.

Event Timeline

Tentatively marking this as a train blocker, in case it’s a MediaWiki bug – we wouldn’t want something like this to hit production. It might just as well be a Beta config issue, though.

Database says I’m a bureaucrat:

MariaDB [enwiki]> SELECT ug_group FROM user_groups WHERE ug_user = (SELECT user_id FROM user WHERE user_name = 'Lucas Werkmeister (WMDE)');
+------------+
| ug_group   |
+------------+
| bureaucrat |
| confirmed  |
| sysop      |
+------------+
3 rows in set (0.00 sec)

PHP also agrees:

lucaswerkmeister-wmde@deployment-deploy01:~$ mwscript eval.php enwiki <<< 'var_export( User::newFromName( "Lucas Werkmeister (WMDE)" )->getGroups() )'
array (
  0 => 'bureaucrat',
  1 => 'confirmed',
  2 => 'sysop',
)

But Special:UserRights/Lucas Werkmeister (WMDE) doesn’t show the group:

Member of: Confirmed users, Administrators
Implicit member of: Autoconfirmed users

I am seeing the group from my end.

Screen Shot 2020-01-31 at 5.37.27 PM.png (669×1 px, 181 KB)

Now I’m seeing it as well… maybe the outdated permissions were cached somewhere and now that cache expired?

What's the current status of this? Is this still a train blocker?

I’d say that’s up to the train… manager? person? Anyways, up to you :)

The worst-case scenario is that this is a real MediaWiki core bug that affects not just Beta but also production, and it’s effective not just when someone gains rights, but also when someone loses them, allowing a user to continue exercising their rights for up to a few hours.

On the other hand, if it only makes a difference when someone gains rights but not when someone loses them, it’s more of an annoyance; and it might not affect production at all, but be due to some incorrectly set-up cache in Beta.

(I also haven’t had an opportunity to try if this still happens since Friday.)

zeljkofilipin triaged this task as Unbreak Now! priority.Feb 5 2020, 2:43 PM
zeljkofilipin added a subscriber: zeljkofilipin.

Train blockers are UBN. Feel free to lower priority if this is not a train blocker, but in that case, remove T233866 as parent task.

Jdforrester-WMF lowered the priority of this task from Unbreak Now! to Needs Triage.Feb 5 2020, 6:22 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

We don't think this is a train blocker.

I'm gonna make the call that this isn't serious enough to block the train _yet_ at least not without further evidence that it's affecting production. So I think we will cautiously move forward with the train while monitoring this for further fallout/production impact.

This issue affects production as well, but it's not new in this week's release – I found a duplicate report from 23 January: T243490.

Untagging as per above not an issue with the cluster

matmarex renamed this task from Inconsistent user permissions on Beta English Wikipedia to Inconsistent user permissions for users who were recently added to a new group.Feb 5 2020, 9:32 PM

Maybe the same issue as T234743: User rights validation is sometimes malfunctioning (with FlaggedRevs only?) (depending on which server you hit the group might or might not exist)? Although bureaucrat is a core group and I don't think we remove it anywhere...