Page MenuHomePhabricator

Make the abusefilter-blocker user not be a sysop
Open, Needs TriagePublic

Description

According to a code comment, the user returned by AbuseFilter::getFilterUser() is made a sysop so that "it doesn't look like an unprivileged account is blocking users". Given how precious small wiki communities are about their admin lists, as evidenced by comments on T209565, this may be the lesser of two evils.

Perhaps all users created by User::newSystemUser() could be in a special system user group, that would clear up any confusion about how it is that unprivileged users are able to make privileged actions. The new group would not need any rights assigned to it, since these users act through APIs that do not perform authorization.

In the meantime, note that it is safe to remove the sysop flag from the abusefilter-blocker user using Special:UserRights.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 19 2018, 12:21 AM
Ejs-80 added a subscriber: Ejs-80.Dec 19 2018, 12:48 AM

I think part of this confusion could be solved if we acted upon T160666. We
have several other system users such as MediaWiki default, Maintenance
script, MediaWiki message delivery, Redirect fixer, etc. whose name is one
for all wikis, which helps identifying the account via CentralAuth and
benefits from GlobalUserPage. I feel what we have here with
abusefilter-blocker is an exception. Also, it can cause broken logs if the
abusefilter-blocker string gets modified once it has logs aasigned to the
previous account name, etc. Thanks.

Jni added a subscriber: Jni.Dec 19 2018, 8:42 AM

Originally I didn't really agree with the rationale behind T160666, but now I think that it's actually worth going on with that. We would benefit from centralAuth, and it won't be possible for people to change the account name, or to use invalid characters inside the message, as it happened in kmwiki.
Another thing we need is some way to clearly identify system users, both backend (as discussed for instance here) and frontend, so that users don't get confused.

Daimona moved this task from Backlog to Next on the User-Daimona board.

Two impressions from the communities:

In both cases, there is concern about the abusefilter-blocker user having a (symbolic) sysop flag.

Sincerely I cannot personally understand the concern, as I already said. However, we will do something to change the AbuseFilter user; from my side, I won't be able to do much these days, but I'll try to do something in 1-2 weeks or so. Removing User-notice because I already added it to T209565, together with some message samples.

Meno25 added a subscriber: Meno25.Dec 26 2018, 6:23 AM

Change 481549 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Move the AbuseFilter user name to a global, improve it

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

Daimona claimed this task.Dec 29 2018, 6:06 PM
Daimona moved this task from Next to Under review on the User-Daimona board.

@Adotchar Thanks for reporting. I wrote down a message for Tech/News in T209565#4852173 and it'll be announced on Jan 7th.

@Adotchar Thanks for reporting. I wrote down a message for Tech/News in T209565#4852173 and it'll be announced on Jan 7th.

I put announcement in arwiki about this issue 26 Dec 2018.

Jony added a subscriber: Jony.Jan 3 2019, 8:45 PM
Tgr added a subscriber: Tgr.Jan 9 2019, 3:26 AM

We would benefit from centralAuth

We wouldn't as it is now, newSystemUser creates non-attached local users. We should probably fix that, I don't think the global user page works for non-attached accounts, and that's very useful for system users, even if having a central account on its own isn't. (Granted, we could also just change GlobalUserPage to always show for system users.)

@Tgr If we want it to be the default, yes, it should be fixed in core. For AF, the user is attached on creation (see lines 723-727).
At any rate I think the change should be to attach system users, and not to make exceptions.

Mikemcgee closed this task as Declined.Jan 9 2019, 11:22 AM
Mikemcgee added a subscriber: Mikemcgee.

Cannot be fixed as it accessed to jimmy wales

Daimona reopened this task as Open.Jan 9 2019, 11:23 AM
Daimona removed a subscriber: Mikemcgee.
Mikemcgee renamed this task from Make the abusefilter-blocker user not be a sysop to Sorry it was declined.Jan 9 2019, 11:27 AM
Mikemcgee closed this task as Declined.
Mikemcgee triaged this task as Unbreak Now! priority.
Mikemcgee removed Daimona as the assignee of this task.
Mikemcgee updated the task description. (Show Details)
Mikemcgee removed subscribers: Tgr, Ninjastrikers, Jony and 16 others.
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptJan 9 2019, 11:27 AM
Mikemcgee lowered the priority of this task from Unbreak Now! to Needs Triage.Jan 9 2019, 11:31 AM
Nirmos renamed this task from Sorry it was declined to Make the abusefilter-blocker user not be a sysop.Jan 9 2019, 11:32 AM
Nirmos reopened this task as Open.
Nirmos updated the task description. (Show Details)
Tgr added a comment.Jan 9 2019, 6:36 PM

@Tgr If we want it to be the default, yes, it should be fixed in core. For AF, the user is attached on creation (see lines 723-727).

Oh, wasn't aware of that. It's a very Wikimedia-specific hack though. The generic approach (which might or might not blow up spectacularly; also we'd probably want something like T69936 for it, and not just in AbuseFilter) would be to create the user with AuthManager::autoCreateUser(). https://gerrit.wikimedia.org/r/c/mediawiki/core/+/481554/ is somewhat related.

Izno added a subscriber: Izno.Jan 13 2019, 4:41 AM
Tegel added a subscriber: Tegel.Jan 20 2019, 5:16 PM

@Tgr I'm sorry but I'm not sure I understood. Is it correct that, after $user = User::newSystemUser( $wgAbuseFilterUserName, [ 'steal' => true ] ); (line 720) we should do

MediaWiki\Auth\AuthManager::singleton()->autoCreateUser(
	$user,
	MediaWiki\Auth\AuthManager::AUTOCREATE_SOURCE_MAINT,
	false
);

instead of dealing directly with CentralAuth?

Tgr added a comment.Jan 22 2019, 4:28 PM

Yes, although maybe that should be put into newSystemUser itself.

Tgr added a comment.Jan 25 2019, 8:15 PM

Hm, no, actually that wouldn't work; CentralAuth refuses autocreation attempts if there is a central user by that name. Let's move this to a separate task to avoid side-tracking too much here: T214722: Introduce global system users

Change 481549 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Move the AbuseFilter user name to a global, improve it

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