I'm guessing this is because they're performing 'upload' actions instead of 'edit' actions, and only edit could be protected by cascading protection from non-file pages? What if you add {{File:B}} to File:A's description, cascade-protect File:A from uploading, then try to revert uploads on File:B?

In T140010#2450976, @Krenair wrote:

I'm guessing this is because they're performing 'upload' actions instead of 'edit' actions, and only edit could be protected by cascading protection from non-file pages? What if you add {{File:B}} to File:A's description, cascade-protect File:A from uploading, then try to revert uploads on File:B?

The longstanding behavior is for the transclusion of a file on a cascade-protected page to prevent non-admin uploads under the relevant filename. For this reason, the English Wikipedia has (against my advice) come to rely on this function as a first-line protection method for images appearing on its main page. (A Commons bot monitors the upcoming images and transcludes them on a cascade-protected page.)

It remains impossible for someone using a non-admin account to upload an entirely new version of such a file; he/she may only revert to a previous revision publicly visible in the file's history.

I just tried transcluding my test image on the test video's description page, which I cascade-protected. This registered as an additional source of cascading protection for the image, but I still was able to perform a reversion via my non-admin test account.

I think this is a duplicate of T24521. That task has had a patch pending for nearly a year (https://gerrit.wikimedia.org/r/#/c/233207/). I think people are afraid to merge it, since it's security-sensitive code.

In T140010#2454353, @matmarex wrote:

I think this is a duplicate of T24521.

If I understand correctly, that's a request to change cascading protection's behavior by applying the resultant protection to the file alone (instead of both the file and the description page).

That isn't directly relevant to the issue that I'm reporting. The problem is that cascade-protecting a file has stopped preventing non-admin reversions to previous revisions of said file. This malfunction seems to have begun no earlier than 3 July 2016. (I fulfilled a related request on that date, so I know that the non-admin reversion prevention was in effect.)

Oh basically cascading protection protects the edit permission only. For a normal upload; both edit and upload are required; but a reversion only needs upload, unprotected by cascading protection.

I'm unaware of the last issue (which caused this bug) when I wrote the above patch.

In T140010#2450976, @Krenair wrote:

What if you add {{File:B}} to File:A's description, cascade-protect File:A from uploading, then try to revert uploads on File:B?

T62109

Edit 1: Never mind, they should inherit the protection in this case (at least that's what my knowledge of cascade protection says).

Edit 2: Thinking again, if the left side of https://gerrit.wikimedia.org/r/#/c/233207/9/includes/Title.php is still the current algorithm, that won't work; File:A's description must be [[File:B]] instead of {{File:B}} to have an imagelink to inherit the protection.

Discovered an inconsistency:

• RevertAction.php needs upload only
• ApiFileRevert.php needs both edit and upload, similar to normal uploads

Both of these are from 2011 or before, per blame

There was a discussion on IRC regarding the weirdness of cascading protection on File:Moon_Jae-in_May_2017.jpg, which should be cascade-protected by both Commons:Auto-protected_files/wikipedia/fr & Commons:Auto-protected_files/wikinews/en

https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=326963106#Cascading_protection_doesn't_stop_me_from_overwriting_files

In T140010#2455301, @zhuyifei1999 wrote:

Discovered an inconsistency:

• RevertAction.php needs upload only
• ApiFileRevert.php needs both edit and upload, similar to normal uploads

Both of these are from 2011 or before, per blame

Nice catch. That should be fairly straight-forward to patch to require edit and upload in both places.

It does not make sense to require edit permissions in the first place. Besides, that 'workaround' is dependent on the current behavior of T24521: Cascade-protecting files should protect the file, not the description page, and have it never fixed.

This is quite easy to fix without reworking parts of PermissionManager. Are there any issues with the below patch? This will mean the revert will require edit, so edit protection will prevent reverts, but this is already existing behavior with normal upload and if T24521 is resolved then this can be changed. I've also added a check for reupload as the right is required to overwrite existing files, which revert does.

Another similar patch has been submitted for review in November: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/737454

In T140010#7616936, @matmarex wrote:

Another similar patch has been submitted for review in November: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/737454

That patch removes a check for upload using the action page, this isn't ideal as upload is a prerequisite for reupload/reupload-own and would allow users to revert files if the user group is assigned reupload/reupload-own but not upload. An example in WMF production are closed wikis, where upload rights are removed, however user groups may still have reupload/reupload-own rights. AFAIK This would allow users to modify closed wikis as long as they already have an account there.

Just noting https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1112359 would fix this.

Indeed it would, thanks for noting it here.

I would like to merge that patch. @sbassett @Reedy I have two questions for you before I do that:

• Is this something that should be backported to release versions? (It looks easily backportable to 1.42 with minor fixes, more challenging to backport to 1.39.)
• Is it okay to just merge it, or would you like to coordinate it with the MediaWiki release timing somehow?

In T140010#10533370, @matmarex wrote:

• Is this something that should be backported to release versions? (It looks easily backportable to 1.42 with minor fixes, more challenging to backport to 1.39.)

In general, from a Security-Team perspective, we try to backport security fixes to any relevant supported release branches. If code never existed on an older release branch or was only briefly an issue on master or something, then it can't be backported. If it's non-trivial but possible to backport, I think that usually ends up being a judgment call for the developers/maintainers of the code.

• Is it okay to just merge it, or would you like to coordinate it with the MediaWiki release timing somehow?

If we're talking about c1112359 above, as long as it goes through standard CR and tests fine, I think it can just be merged, as it's already a public change set.

Change #1112359 merged by jenkins-bot:

[mediawiki/core@master] PermissionManager: Differentiate between cascading protection of file content and file pages

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

@sbassett Changes are live now. Would you please make this task public?

I added a draft entry for this and other recent work on cascading protection and file uploads to the Tech News for the week after next (so that we have some more time to discuss and edit them, as these changes are difficult to explain with brevity): https://meta.wikimedia.org/wiki/Tech/News/2025/10

Change #1130586 had a related patch set uploaded (by Reedy; author: Dylsss):

[mediawiki/core@REL1_43] PermissionManager: Differentiate between cascading protection of file content and file pages

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

Change #1130587 had a related patch set uploaded (by Reedy; author: Dylsss):

[mediawiki/core@REL1_42] PermissionManager: Differentiate between cascading protection of file content and file pages

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

Change #1130588 had a related patch set uploaded (by Reedy; author: Dylsss):

[mediawiki/core@REL1_39] PermissionManager: Differentiate between cascading protection of file content and file pages

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

Do we know offhand how long this has been around for?

Change #1130586 merged by jenkins-bot:

[mediawiki/core@REL1_43] PermissionManager: Differentiate between cascading protection of file content and file pages

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

Change #1130587 merged by jenkins-bot:

[mediawiki/core@REL1_42] PermissionManager: Differentiate between cascading protection of file content and file pages

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

Change #1130588 abandoned by Reedy:

[mediawiki/core@REL1_39] PermissionManager: Differentiate between cascading protection of file content and file pages

Reason:

Complexity and duplication...

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