Last modified: 2011-03-13 18:05:39 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 5882 - Admin session protection by requiring to re-enter their password to use any admin operation (a feature like "sudo")
Admin session protection by requiring to re-enter their password to use any a...
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-05-09 12:15 UTC by Anon Sricharoenchai
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

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


Description Anon Sricharoenchai 2006-05-09 12:15:47 UTC
This is a feature that has a "sudo"-like behavior for any admin operation.

Any admins (sysop, bureaucrat) must be required to re-enter their password to
use any admin operation.
1. When the admin user first login, they have all privileges with exactly the
same as normal login user.
2. When the admin user first click the link that require admin privileges (such
as, delete, protect, block user), they will be prompted with password dialog
box.  They must re-enter their password to gain the admin privilege session, so
that they can continue the admin operation.
3. They won't be required to re-enter the password, to do any subsequent admin
operation, within the limited expiration time (since last admin operation).
4. The session with admin privilege will expire, after a limited time since last
admin operation.
5. When the session expire, they need to re-enter the password, to do the
subsequent admin operation.
6. Must have logs for every admin operation.  Not only delete/protect/block
operations which are already logged, the other admin operations, such as,
viewing the deleted page, editing the protected page, rollback the page, should
also be logged.
7. Optionally, the admin may be required to give their reason to view any
deleted page.  The reason will be shown in the log that record the viewing of
deleted page.

== Rationale ==
Comment 1 Rob Church 2006-05-09 12:31:16 UTC
I'd be inclined to WONTFIX this, to be honest; the rationale being that it would
place too great an emphasis on administrator permissions and it would get in the
way of administrators responding to both casual issues and time-sensitive
"threats". The other two main concerns this report raises are auditing. Editing
protected pages is logged in the pages' histories as any other edit would be;
rollback operations are also logged here.

Viewing of deleted pages might be a problem in some cases, but I'd be inclined
to suggest that pages which have been deleted for legal reasons, etc. should be
deleted using the [hopefully] forthcoming improved revision deletion mechanism.
Alternatively, they should be wiped from the database.
Comment 2 Anon Sricharoenchai 2006-05-09 13:19:37 UTC
For a time-sensitive "threats", a session timeout can solve this problem.
The session timer will be reset whenever the admin operation is used.
This is alike to "sudo" command in most unix-like system.
If the admin use the admin-privileged command continuously or periodically, they
will never be required to re-enter their password.
But this doesn't mean to encourage the admin to continuously overuse the admin
It means that if they "really" need to continuously use the admin operation,
such as in a time-sensitive situation, they can do that in time.

BTW: I just added the 4th item in rationale session of,
Comment 3 Rob Church 2006-05-09 14:45:15 UTC
I still don't understand why you'd bother to add "sudo"-like functions in the
first place. And what's with the "overuse" argument? It makes no sense
whatsoever to add needless crippling of functionality like this.
Comment 4 Platonides 2006-05-10 14:59:30 UTC
I answered on that page your arguments. Please try to get some consensous on
problematic changes before asking them to be done.
Comment 5 Rob Church 2006-05-10 15:04:24 UTC
It's not that the change was problematic, it's that the idea doesn't fit the
direction the software should be following.
Comment 6 Platonides 2006-05-10 16:12:09 UTC
I meant "socially problematic" :)
Comment 7 Anon Sricharoenchai 2006-05-15 12:20:39 UTC
Ok, I will revise the feature to be the more relax and flexible, to not affect
the existing culture/tradition (in case they have consensus not to change them).
The feature may be disabled by default when upgrading, to not have impact on the
existing project.
Some new project using mediawiki may want this feature.
I, personally, as an admin of, extremely need this
feature in that wikia sub-domain.
Comment 8 Anon Sricharoenchai 2006-05-15 13:26:47 UTC
Hi, adding more compromise specification,

8. It will depend on the config on each wiki project to allow admin user to
setup the session expire time (or to not expire at all) in his/her preferences.
9. When upgrading mediawiki, the admin session expire time will be, by default,
not expire at all, to not have impact on the existing project.

for more details of change.

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