Page MenuHomePhabricator

Global suppression does not work properly when the target has already been locally blocked
Open, HighPublic

Description

The problem

When an account gets blocked at any project before stewards could change its global status via CentralAuth, if the steward tries to globally suppress the account, CentralAuth will successfully suppress the account on all projects but on those where the account has been blocked locally. CentralAuth should override local block settings if we decide to globally suppress the account.

Steps to reproduce

  • User:Abusive-username is created and SUL propagates to several other projects and vandalizes.
  • An administrator at a given project blocks the account locally.
  • A steward notices the abusive name and locks and suppresses the account via CentralAuth
  • Result: CentralAuth will block the account at all projects with the 'hideuser' flag enabled but will fail on the project where the admin blocked the account, hence the steward has to manually reblock the account there to remove it from public view.

Workarounds

  • We've been given a script by Glaisher to work around this.

Problems

  • Possible problem when reversing the action. CentralAuth should not remove local hideuser blocks imposed by their local oversighters in case of global unsuppression.

Details

Reference
bz23310

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz23310.
bzimport added a subscriber: Unknown Object (MLST).

Hello. Any updates on this? This is potentially causing privacy leaks as explained above. Scaling up to critical and CC'd Tim. Sorry for bothering but this needs urgent fixing. Thanks.

vvv added a comment.Mar 22 2011, 8:36 AM

I'm not sure about that. It should remove users from user list, and it did when I commited it.

(In reply to comment #2)

I'm not sure about that. It should remove users from user list, and it did when
I commited it.

Not when the user is previously blocked before we can globally suppress it. Regards.

(lowered priority as carry over from old bug triage)

Brian:
This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED.
In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help!
[assigned>=1y]

hoo added a subscriber: hoo.Feb 28 2015, 2:49 PM
Glaisher raised the priority of this task from Low to Normal.Apr 16 2015, 6:02 PM
Glaisher added a subscriber: Glaisher.

There are two options for hiding in CentralAuth. That is "hiding from public lists" and "hiding completely". These two behave differently.

  1. Hiding from public lists means it only the global stuff (i.e., only CentralAuth related stuff). It will hide the username from Special:GlobalUsers and make Special:CentralAuth pretend that there is no such username (for users without the sufficient rights).
  2. Hiding completely means actually suppressing it (i.e. what HideUser does). It will hide everything about the local account as well not just the global account (from logs, Special:ListUsers, Special:BlockList etc.)

However, I noticed that global suppression does not work well when the user is already blocked before the global suppression is done. It does work as expected if the user was suppressed prior to the local block. So from what I can see, that is what this bug is actually referring to.

Most of the time, accounts with abusive usernames are reported to stewards while they've already been locally blocked. So this bug should be encountered quite frequently. As such, this shouldn't be a low priority bug as MA stated.

Glaisher renamed this task from CentralAuth: global suppression does not suppress very well to Global suppression does not work properly when the target has already been locally blocked.Apr 16 2015, 6:03 PM
Glaisher set Security to None.
Glaisher updated the task description. (Show Details)
Glaisher removed a subscriber: Unknown Object (MLST).
Glaisher claimed this task.Apr 19 2015, 5:01 AM

Currently, it first tries to insert a hideuser block and if the block fails (because there is an existing block), it tries to show an error message that the account is already blocked and the function gets terminated from there. But this message gets lost somewhere in between and doesn't reach the user. Since RevisionDeleteUser::suppressUserName is after the return, the whole process (silently) fails for blocked users.
The admin already knows that the user is blocked from Special:CentralAuth interface so trying to show an error message that there is an existing block doesn't seem useful when attempting global suppression. So instead of showing an error message, I think the solution would be to modify the existing block and then do suppressUserName.

Looks like a good analysis and solution.

If this is ever fixed, I think we should run a script that checked all accounts locked + oversighted to see if there are old accounts that were locally blocked and were not properly suppressed, so they can be finally rightly suppressed.

IIRC there was also a bug when if we try to unsuppress the account, the local accounts will remain locally blocked and suppressed.

Best regards.

Change 205082 had a related patch set uploaded (by Glaisher):
Block: allow to query other DBs in update(), newLoad(), newFromTarget()

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

Change 205083 had a related patch set uploaded (by Glaisher):
Properly handle blocked users in CentralAuthUser::doLocalSuppression

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

Listing similar tasks: T25654, T28476.

Modifying the existing block introduces another issue related to T28476. Global unsuppression will unblock the user even if the user was previously locally blocked. I haven't looked much but I don't think there's a way to retrieve the previous block settings. So we could either change the block to a normal block (change ipb_deleted to 0 again) or b) unblock the user completely. Of course, these are the options assuming we can't retrieve the previous block settings. @hoo is it possible to retrieve the previous block settings?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 19 2015, 5:28 PM

Until we can agree on what to do in these cases, I'll abandon the changes.

Change 205083 abandoned by Glaisher:
Properly handle blocked users in CentralAuthUser::doLocalSuppression

Reason:
Per task

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

Change 205082 abandoned by Glaisher:
Block: allow to query other DBs in update(), newLoad(), newFromTarget()

Reason:
Per task

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

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 7 2016, 2:51 PM
Mattflaschen-WMF merged a task: Restricted Task.May 12 2016, 11:14 PM
MarcoAurelio raised the priority of this task from Normal to High.

The need for a feature like this has increased, specially since the scripts we used to do so are broken now. Thank you.

MarcoAurelio raised the priority of this task from High to Unbreak Now!.Aug 22 2016, 7:08 AM

Given the current issues ongoing, the need for this is very high. As a workaround solution, if https://meta.wikimedia.org/wiki/MediaWiki:Gadget-hideuser.js could be fixed to work again it'd be greatly appreciated.

Restricted Application added subscribers: Luke081515, TerraCodes. · View Herald TranscriptAug 22 2016, 7:08 AM
MarcoAurelio lowered the priority of this task from Unbreak Now! to High.Aug 22 2016, 8:45 AM

I have written https://meta.wikimedia.org/wiki/User:Glaisher/globalSuppress.js as it's not easy to do this server-side without resolving the aforementioned issues. I have done some testing of it at beta cluster and it seems to work okay but do NOT use it yet because I'm not completely sure it would work properly in all cases. It would be nice if I could coordinate with a steward who is willing to help, preferably on IRC, so that we can make it ready for production use.

Glaisher removed Glaisher as the assignee of this task.Aug 24 2016, 5:59 AM

I have written https://meta.wikimedia.org/wiki/User:Glaisher/globalSuppress.js as it's not easy to do this server-side without resolving the aforementioned issues.

Thank you!

I have done some testing of it at beta cluster and it seems to work okay but do NOT use it yet because I'm not completely sure it would work properly in all cases.

Ack.

It would be nice if I could coordinate with a steward who is willing to help, preferably on IRC, so that we can make it ready for production use.

Thank you. I'll ping you on IRC for this shortly.

Tgr added a subscriber: Tgr.Feb 11 2018, 12:16 AM

Is global unsuppression something that happens frequently? Sounds like a very fringe failure mode compared to the current one.

In T25310#3960973, @Tgr wrote:

Is global unsuppression something that happens frequently? Sounds like a very fringe failure mode compared to the current one.

Not that I'm aware of, at least on the global level.

revi added a subscriber: revi.Mar 5 2018, 5:41 PM
Rxy added a subscriber: Rxy.Apr 21 2018, 6:19 PM
Samtar added a subscriber: Samtar.Apr 23 2018, 3:39 PM
Rxy moved this task from Backlog to ToDo on the User-Rxy board.
RuyP added a subscriber: RuyP.Jan 17 2019, 6:26 PM