Blocked administrator inconsistencies
OpenPublic

Description

Author: haistaes

Description:
When blocked, on one's own talk page one:

*can load the move form, but cannot submit (although the blocked header which is returned is malformed)
*can change the protection levels
*can delete the page, but cannot undelete (but can recreate as intended)

Additionally, when blocked, one can block and unblock other users.

Expected results:
*One should not be able to undertake any admin functions on one's own talk page whilst blocked
*One should not be able to block or unblock other users whilst blocked


Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz15641.
bzimport created this task.Via LegacySep 18 2008, 6:15 PM
bzimport added a comment.Via ConduitSep 18 2008, 6:16 PM

river wrote:

I believe blocking and unblocking users while blocked was discussed before and the decision was this should be allowed. (Unfortunately, I don't remember the reasons, or where that was.)

demon added a comment.Via ConduitSep 18 2008, 6:25 PM

(In reply to comment #1)

I believe blocking and unblocking users while blocked was discussed before and
the decision was this should be allowed. (Unfortunately, I don't remember the
reasons, or where that was.)

Two scenarios I can think of:

A) There's only 1 sysop. He blocks himself. Now he can't unblock himself unless someone tweaks the database.

B) There's two sysops. One goes rogue and blocks the 2nd. 2nd is now incapable of doing anything.

I can't remember where this was discussed, but I believe these were the reasons.

bzimport added a comment.Via ConduitSep 18 2008, 7:00 PM

majorly.wiki wrote:

(In reply to comment #2)

(In reply to comment #1)
> I believe blocking and unblocking users while blocked was discussed before and
> the decision was this should be allowed. (Unfortunately, I don't remember the
> reasons, or where that was.)
>

Two scenarios I can think of:

A) There's only 1 sysop. He blocks himself. Now he can't unblock himself unless
someone tweaks the database.

B) There's two sysops. One goes rogue and blocks the 2nd. 2nd is now incapable
of doing anything.

I can't remember where this was discussed, but I believe these were the
reasons.

That's for blocking/unblocking themselves. We need the reasons for *other* users.

bzimport added a comment.Via ConduitSep 18 2008, 7:22 PM

haistaes wrote:

The standard concept seems to be that you can't undertake any editorial or administrative action when blocked besides:
*editing your own talk page (to communicate)
*unblocking yourself (for technical reasons outlined above)

The matters I have highlighted, as comment #3 said, seem inconsistent with this. You should have to be unblocked (or unblock yourself) to do any more, adding a layer of accountability.

IAlex added a comment.Via ConduitFeb 10 2010, 4:05 PM
  • Bug 21882 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitFeb 10 2010, 6:11 PM

FT2.wiki wrote:

(Copied from bug 21882)

An administrator who is blocked, should lose the use of most admin tools,
except perhaps the passive IP Block Exemption, and the ability to block and
unblock.

Rationale:

Blocking admins happens very rarely, in general only when there is a concern
about present and immediate conduct, sysop account compromise and the like and
while waiting for the local temporary desysop process to be completed.

When an administrator account is blocked, it seems illogical that they cannot
edit, but they can delete, undelete, protect, unproptect, view deleted
material, and so on.

Admin tools are more sensitive and require more trust than editing tools. A
sysop account that is blocked, should lose the tool access until the matter is
resolved, subject to keeping IP Block Exemption (needed to post appeals or
responses) and block/unblock ability (for test purposes when an admin
self-blocks or their IP is accidentally blocked)

Misuse of the block/unblock tool will be noticed by the community and met by the further step of removing that account's sysop access if needed, hence not an
issue. It is easier to allow block/unblock on that basis than to figure what
unblocks they may need to do on various MW installations, to remedy a problem.

bzimport added a comment.Via ConduitFeb 10 2010, 6:14 PM

FT2.wiki wrote:

Noting also from bug 21882 that "per permission" blocking is not what's needed. There are very many permissions a user can have. This issue is one item and should ideally be automatic (shouldn't need any checkbox).

bzimport added a comment.Via ConduitMar 26 2010, 10:05 PM

happy.melon.wiki wrote:

Access to block/unblock fixed in r64228: blocked admins cannot block or unblock other users, nor unblock themselves unless they have the 'unblockself' right.

bzimport added a comment.Via ConduitApr 21 2010, 10:55 PM

charitwo wrote:

It seems that blocked users with the appropriate rights can still import pages via XML.

bzimport added a comment.Via ConduitMar 30 2011, 2:08 PM

happy.melon.wiki wrote:

Fixed in r85005.

bzimport added a comment.Via ConduitJul 23 2011, 9:00 PM

rd232 wrote:

As far as I can tell blocked administrators still have access to some administrative rights, in particular "browserarchive", "deletedhistory", and "deletedtext". These should also be suspended when blocked. Indeed, with the sole exception of self-unblocking (because of mistakes and "rogue admin" scenarios in small wikis), I would have thought that blocked users should only have access to whatever user rights are associated with the "all editors" group.

At any rate, on Wikimedia wikis, having blocked administrators - potentially compromised accounts whose status is not yet clear enough to desysop - able to access deleted material, even for a few hours or days, seems BAD, given the WMF emphasis on these rights being sensitive.

bzimport added a comment.Via ConduitJul 26 2011, 8:57 PM

happy.melon.wiki wrote:

This should be fixed in r93206. Feel free to reopen if you find any more permissions that admins shouldn't have while blocked.

MaxSem added a comment.Via ConduitOct 7 2011, 1:59 PM

Reverted in r93246.

MaxSem added a comment.Via ConduitOct 7 2011, 2:03 PM

Grr, r99211.

bzimport added a comment.Via ConduitOct 7 2011, 2:05 PM

happy.melon.wiki wrote:

For reference, I like the implementation idea for this I brainstormed in r93246 CR (basically making "isblocked" an implicit group which we can then use with $wgRevokePermissions).

demon removed a subscriber: demon.Via Bulk EditWed, Aug 19, 4:41 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldWed, Aug 19, 4:41 PM

Add Comment