Last modified: 2011-03-13 18:05:24 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 3072 - Remove option to unblock self
Remove option to unblock self
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 9851 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-08 15:30 UTC by Robert Rohde
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

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


Attachments

Description Robert Rohde 2005-08-08 15:30:21 UTC
Admins should never fight, and if they do fight, they certainly should 
never get into blocking wars.  Standard practice says that admin should, 
like anyone else, petition another admin to be unblocked if they believe 
they were blocked unfairly.  I would request that this be enforced at the 
technical level by removing the option for an admin who is blocked to 
unblock himself.

It may also be worth considering whether or not all of the sysop tools 
should be disabled when an admin is blocked.
Comment 1 Brion Vibber 2005-08-08 15:34:51 UTC
A couple major problems:
* If a rogue admin blocks all other admins, no one else can recover 
without external assistance.
* If a range or IP block accidentally hits an admin, the admin cannot 
recover. On a small wiki with a single admin this may be unrecoverable 
without interference in the database.

If there is a need to block a sysop, it would make sense to desysop that 
account first.
Comment 2 ABCD 2005-08-08 15:42:08 UTC
A third problem - if an admin wants to test using blocks, usually the admin will
simply test by blocking him- or herself.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-09 16:27:31 UTC
*** Bug 9851 has been marked as a duplicate of this bug. ***
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-09 16:33:11 UTC
(In reply to comment bug 9851 comment #2)
> Not to argue, but there is no difference between an admin blocking all and
> acting unchecked, or unblocking himself repeatedly to do that. Except that only
> one of them is likely to delete the main page or edit the sitenotice of a top 10
> website with 100 other admins that it would be impossible to block, practically
> speaking. 

It would be quite easy to write a script to block every other admin on the site
at once.  There are no restrictions on simultaneous blocks.  Presumably to
compromise an account you need to be a script kiddie already, and any script
kiddie could block all other admins.  A much more reasonable request is the
"sacrifice sysophood to desysop" idea, which permits the majority to immediately
deal with a rogue minority without giving the minority any substantial leeway
(desysopping a single user is not very disruptive at all compared to vandalism
of the main page or whatnot).
Comment 5 Robert Rohde 2007-05-09 18:21:06 UTC
One option could be to allow a blocked admin to remove IP blocks and unblock others, but 
not himself.  For wikis with a nontrivial number of sysops that would allow cooperation to 
overcome the "everyone gets blocked" issue, while still limiting the damage that could be 
done by a single rogue account.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-10 00:52:42 UTC
It's simple for a script to block every admin on the wiki simultaneously.  The
logic of a Perl script to do that, given a list of admins, would amount to
probably a few lines.  You just need to send a couple hundred POSTs over the
course of half a second or whatever, and they should all go through without a
hitch.  Resend every half-second for a few seconds if you're worried.  And if
we're worried about compromised admin accounts, presumably they were compromised
by script kiddies who could easily write such a script.

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


Navigation
Links