Last modified: 2013-05-16 23:38:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 47617 - It should be possible to use cascading protection with non-"sysop" protection level
It should be possible to use cascading protection with non-"sysop" protection...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
1.22.0
All All
: Unprioritized normal (vote)
: 1.22.0 release
Assigned To: Bartosz Dziewoński
:
Depends on:
Blocks: 8575
  Show dependency treegraph
 
Reported: 2013-04-24 18:45 UTC by Bartosz Dziewoński
Modified: 2013-05-16 23:38 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bartosz Dziewoński 2013-04-24 18:45:38 UTC
It should be possible to use cascading protection with non-"sysop" protection level. Right now there's a hard-coded check in WikiPage that prevents that, as (quoting a comment above it) "[o]therwise, people who cannot normally protect can "protect" pages via transclusion".

While this is a good point, it is really a policy issue rather than code one in some cases. And if this is a concern, we could have a global named, say, $wgCascadingProtectionLevels that would default to array('protect', 'sysop').

For example, I think that it really should be possible for the 'editor' protection level that's currently enabled on pl.wiki (bug 46990) (there's a similar one on pt.wiki, see bug 39652). This is a FlaggedRevs-related permission (able to mark pages as "checked") automatically granted to semi-trusted users.

The practical use case: we want to lower the protection level of the main page of the Polish Wikipedia to 'editor' while keeping the cascading behavior. Protecting all of the subpages manually is unfeasible, as these are automatically cycled every day, and should be fully editable while not displayed on the main page.
Comment 1 Gerrit Notification Bot 2013-04-24 19:20:09 UTC
Related URL: https://gerrit.wikimedia.org/r/60695 (Gerrit Change I5f8bcc899b46d466161894606cd27bf3b8624bd0)
Comment 2 Bartosz Dziewoński 2013-04-24 19:21:32 UTC
$wgCascadingRestrictionLevels it is. I5f8bcc89.
Comment 3 Bartosz Dziewoński 2013-05-12 11:47:56 UTC
Merged.
Comment 4 Krinkle 2013-05-14 19:39:22 UTC
Quoted from commit message:
> This is necessary, because if any protection could be
> cascading, users could who cannot normally protect pages could
> "protect" them by transcluding them on protected pages they are
> allowed to edit.

Please elaborate on this, especially with regards to the following part of the change:

@@ 	function buildCleanupScript() {
-		global $wgRestrictionLevels, $wgOut;
+		global $wgRestrictionLevels, $wgCascadingRestrictionLevels, $wgOut;
-
-		$cascadeableLevels = array();
-		foreach ( $wgRestrictionLevels as $key ) {
-			if ( User::groupHasPermission( $key, 'protect' )
-				|| $key == 'protect'
-			) {
-				$cascadeableLevels[] = $key;
-			}
-		}
+
+		$cascadeableLevels = $wgCascadingRestrictionLevels;

It now no longer verifies that the values in cascadeable levels are names of user groups that have the "protect" right. Doesn't that cause a situation exactly like the one you appear to be trying to prevent?

Also, from looking at the code, contrary to the commit message it is not hardcoded to 'sysop'. On the contrary, it is dynamically constructed based on wgRestrictionLevels and filtered to only include groups that have the 'protect' right. If I'm reading the use case explained in this bug and in the commit message correctly, it seems that this is already possible without this change.


Re-opening with 1.22 milestone to prevent forgetting about this before release. Feel free to re-close.
Comment 5 Krinkle 2013-05-14 19:41:15 UTC
btw, I see now that WikiPage::doUpdateRestrictions did hardcode the values during an edit attempt. However ProtectionForm did not.
Comment 6 Bartosz Dziewoński 2013-05-14 23:07:40 UTC
> @@     function buildCleanupScript() {
> ...
> +        $cascadeableLevels = $wgCascadingRestrictionLevels;

This is only used to build the client-side list of protection levels which can be cascading; skins/common/protect.js uses it to disable/enable the checkbox when appropriate.


(In reply to comment #4)
> Quoted from commit message:
> > This is necessary, because if any protection could be
> > cascading, users could who cannot normally protect pages could
> > "protect" them by transcluding them on protected pages they are
> > allowed to edit.
> 
> Please elaborate on this

Let's assume the default settings, with the minor change that 'autoconfirmed' protection can be cascading.

You protect [[A]] as autoconfirmed, cascading. An autoconfirmed user transcludes {{:B}} on [[A]]; now [[B]] is protected as well, despite the user not having the rights to protect it, and non-autoconfirmed users can't edit it anymore nor undo the protection.

I think that this can be handled on the policy level instead of on the application level, at least for some semi-trusted groups. That's what this change accomplishes.


> If I'm reading the use case explained in this bug and in the commit
> message correctly, it seems that this is already possible without this
> change.

No. The point is to be able to enable cascading protection for some cases *in spite of* this flaw I explained above, Use case: fully protected main page with recursively semi-protected embedded parts. (There is currently no interface for this, but you can get around it using some clevel transclusion and cascading protection hacks. The schema apparently supports such dual protection, though.)
Comment 7 Bartosz Dziewoński 2013-05-16 23:38:26 UTC
(Re-resolving if everything's clear now.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links