Page MenuHomePhabricator

MassMessage fails to respect a user's partial block
Open, LowestPublic

Description

MassMessage fails to respect a user's partial block from the "User talk" namespace

English Wikipedia Beta Cluster:
05:54, 26 April 2019 DannyS712 talk contribs block blocked DannyS712 talk contribs from editing the namespace User talk with an expiration time of 2 weeks (log)
05:55, 26 April 2019 DannyS712 talk contribs block sent a message to User:DannyS712/mms (Test2) (log)
Since 21:18, 10 April 2019, the only page listed at User:DannyS712/mms was "User talk:DannyS712 test2" (permanent link)
06:01, 26 April 2019 MediaWiki message delivery delivers the message that I sent to User:DannyS712 test2 (diff)

Expected behaviour: MassMessages aren't sent to namespaces the user can't edit
Actual behaviour: MassMessage added to a user talk page, despite me not being able to edit that page myself

Event Timeline

dbarratt added a subscriber: dbarratt.

This is working as expected. When a user is blocked from the User_talk namespace, the "Editing their own talk page" prevention option takes precedence (which is the same behavior as a sitewide block).

Since this block does not have that option set, then you are allowed to edit your own talk page:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:BlockList?wpTarget=DannyS712

If this issue persists when editing other talk pages, please re-open. :)

wait a second... are you sending a message from DannyS712 to DannyS712 test2? Which is making an edit on User_talk:DannyS712_test2?

Oh! I see, your user doesn't actually make the edit, the MediaWiki message delivery user does:
https://en.wikipedia.beta.wmflabs.org/w/index.php?diff=392331
since the blocks were checked against that user and not your user it was allowed.

I feel like a user who is trusted enough to be able to perform MassMessages is unlikely to be subject to a partial block like this?

I feel like a user who is trusted enough to be able to perform MassMessages is unlikely to be subject to a partial block like this?

Which would mean that no admin could ever be partially blocked without removing their rights... its a loophole that I believe should be address

Which would mean that no admin could ever be partially blocked without removing their rights... its a loophole that I believe should be address

I can't deny that it's a loophole of course :) but I just cannot imagine a situation in which someone holding admin rights on a wiki would be partially blocked from editing the user talk namespace.

Mostly I'm pointing that out because it might help to triage the priority here. (In any case, I think this particular request would require MassMessage to be rewritten, since I don't think it checks the user's block status before sending ... Might be wrong there.)

I'm fairly sure blocked users can't send mass messages. Regardless, I only tested it at user talk. The same applies to every namespace that mass message can edit in. That being said, I agree that the potential for exploitation is low, and suggest a triage of "low"

Legoktm added a subscriber: Legoktm.

Sitewide blocked users cannot send mass messages. Partial blocks don't really make sense, because everywhere else permissions are checked against the MassMessage sender user, e.g. when deciding whether it has permission to edit a protected page or not.

The only thing I could see worth supporting would be a partial block against Special:MassMessage (is it even possible to partial block special pages?) preventing the user from sending out a message, but at that point you'd just revoke their permissions.

Now if you partial block the MassMessage user (MediaWiki message delivery), that should respect the block and not edit the page.

It looks like the list of targets is generated when the user creates the mass massage (this is later passed to a job which actually writes the message). The way I would resolve this is by checking the block (using PermissionManager::isBlockedFrom() ) on each target before it is added to the job. Effectively, Mass Messages will not be delivered to pages you are blocked from editing.

Niharika triaged this task as Lowest priority.
Niharika added a subscriber: Niharika.

@Legoktm If you don't mind, I think we should keep this ticket open. It is a valid loophole, like @DannyS712 mentioned. I agree with @jrbs that it's highly unlikely this would ever happen in practice but it is a valid problem nonetheless.

DannyS712 moved this task from Archive to Next on the User-DannyS712 board.

Within the MassMessageJob::sendMessage, after checking isOptedOut, we should add a new check, userBlockedFrom, that determines if the sending user can edit the target page. If not, a new local skip with the reason block should be logged. This should also have the benefit of ensuring that a user that is blocked on one project (for example enwiki) cannot send a global mass message to pages on a site they are blocked on (eg from meta). @Legoktm @Niharika would this be okay?

Change 539728 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/MassMessage@master] [WIP] [DNM] Make MassMessage deliver respect blocks

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

Just like my comment in T194529, I think this may be better dealt with with an overall "actions" list for partial blocks. Currently we have a couple of actions that someone can be blocked against (createaccount, sendemail) - why not have more - which should solve other tickets as well? UPLOAD and MOVE seem like ideal early candidates. massmessage really is a limited offering, so I'm not too concerned with this "loophole" - but the concept could use the same enforcement mechanics perhaps?

Change 539728 abandoned by DannyS712:
[WIP] [DNM] Make MassMessage deliver respect blocks

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

DannyS712 removed a project: Patch-For-Review.

I think blocking MessMessages would create more problems than it would solve. Massmessages which are not delivered to single persons because of partial blocks seem to be quite problematic to me.