Page MenuHomePhabricator

Check global rights during autocreation
Open, Needs TriagePublic

Description

We want to do various permission checks during autocreation (e.g. maybe the user's IP is blocked but they have the ipblock-exempt right as global sysops?), but there doesn't exist any good mechanism in MediaWiki to do this, since the local account doesn't exist yet.

Some options:

  • Just support anonymous User objects with a name set (e.g. CentralAuth checks $user->isRegistered() before giving it any rights, it would instead check $user->isRegistered() || $user->isItemLoaded( 'name' )). Simple but scary.
  • Create a new hook, or maybe a service similar to CentralIdLookup, which takes a username and tells if that username has any global rights. It would be the caller's responsibility to ensure that the user is authenticated with the given central ID. The autocreation logic would probably be the only caller ever so this feels like overkill.

Event Timeline

I stumbled on this semi-surprising behavior today. My https://meta.wikimedia.org/wiki/Special:CentralAuth/BDavis_(WMF) staff account has the global-ipblock-exempt permission, but I was unable to attach by login at https://as.wikiquote.org. I received this error notice instead of the expected successful login:

Auto-creation of a local account failed:

Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪Metawiki>Bsadowski1‬. The reason given is Open proxy/Webhost: See the help page if you are affected: Abused web host / VPS: .

Start of block: ১০:০৫, ২৭ ফেব্ৰুৱাৰী ২০২৩
Expiry of block: ১০:০৫, ২৭ ফেব্ৰুৱাৰী ২০২৫

Your current IP address is 2001:470:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX. The blocked range is 2001:470:0:0:0:0:0:0/32.

Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

Per T330602: Special:CreateLocalAccount should comply with user's block-bypass permissions Special:CreateLocalAccount now does take ipblock exemptions into account, so you can ask a steward or meta admin to create your account.

Just support anonymous User objects with a name set ... Simple but scary.

I guess it's not that scary. What are the situations in which you have a named anonymous account?

  • Before autocreation. Adding rights would fix this bug, doesn't otherwise seem problematic (the worst thing that can happen is that the account does / doesn't get autocreated when it shouldn't / should).
  • During revision import (although I'm not sure the current implementation uses User objects at all). Permissions of the revision author don't matter.
  • For global blocks. Again, the permissions of the block author don't really matter.

The potentially scary scenario would be the one where someone registers an unattached local account which unherits permissions from a different user's central account, maybe via a race condition in registration; but the extension should already handle such race conditions (the old and new names are blocked from creation for the entire duration of the rename). So I think we can go with the simple solution here.

The same situation can also arise during normal account creation, once T354928: Allow logging and possibility to enact mitigations for actions for IPs with negative IP reputation data is in place. And we could probably simplify CheckBlocksSecondaryAuthenticationProvider too.

Tgr removed Tgr as the assignee of this task.Jan 12 2024, 7:42 PM
Tgr moved this task from Current Sprint to Soon on the MediaWiki-Platform-Team board.

Never mind, I got confused, this is not actually relevant to T354928. We should probably still fix it soon, but it isn't a blocker for ongoing work.

Change #1017883 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/extensions/CentralAuth@master] look up global user rights for anon users with name set

https://gerrit.wikimedia.org/r/1017883

The above patch fails CI for three tests not in the Database group. All three call User::isAllowed() at some point, which now would require database access. Two tests are in ConfirmEdit and one is in core (DumpableObjectsTest). I could add al lthree to @group Database or I could mock out CentralAuthHooks and have the onUserGetRights method always return true in those tests, or maybe there's some better approach. Poking @Tgr for advice or a pointer.

The problem is that User::isRegistered() tries to load the user, and User::isItemLoaded( 'name' ) is always true if we tried to load the user, even if it's an anonymous user.

The simplest solution would be to use $user->mFrom === 'name' instead of $user->isItemLoaded( 'name' ) but that's one of those grandfathered-in public properties that we probably don't really want to be public. Or we could check whether the username is an IP address but that feels convoluted.

Maybe there should be something like a User::hasUsername() method which is true iff the user has a non-zero ID (after loading) or has been created from a username.

Change #1019731 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/core@master] add a tiny helper function to check if a User has a name set

https://gerrit.wikimedia.org/r/1019731

Change #993242 had a related patch set uploaded (by XtexChooser; author: XtexChooser):

[mediawiki/core@master] AuthManager: perform auto-creation as target user

https://gerrit.wikimedia.org/r/993242

Change #993242 merged by jenkins-bot:

[mediawiki/core@master] AuthManager: perform auto-creation as target user

https://gerrit.wikimedia.org/r/993242