The Problem: Administrators of any online collaboration platform, including Phabricator, typically discover a need for all-access or near-all-access controls in order to properly maintain the community. Many Phabricator users have expressed a desire for these kinds of features.

Some examples of the need for these controls:

• A change needs to be made to an object for accuracy, but the user with edit privileges is unavailable for an extended period of time.
• An object is given incorrect view/edit privileges, thereby preventing necessary admin management (edit, remove, etc) without opening policy where possible. This is especially problematic on objects that should not have "All Users" policy.
• Pedantic (but important) cleanup work - file permissions wrong on an attached file, wrong linked object codes, broken links, closing outdated polls - where requesting changes by the user is either impossible or a royal pain in the keister.
• Administrative conflict resolution - removing inappropriate material from comments/objects (such as flaming or community rule violations) without destroying useful information also present on the material.
• Cleanup from deactivated/banned users - right now, either policy has to be opened fully (where even possible), or the deactivated account has to be taken over by the admin. In the latter scenario, cleanup is not credited to the admin (which looks really awkward at times. (Minor.)

However, the equally weighty problem that @epriestley and @chad have brought up is that, if compromised, an all-access admin account is now an open door to crackers. Simply put, the benefits of an all-access accounts are far outweighed by the security risk.

The Current Solution: To offset the inconvenience, anyone with access to the server controls (a far more secure interface) can manage Phabricator user accounts and perform some override actions (such as freeing some object policies). This does not provide the full set of obvious or necessary controls, however, and many actions (especially edits) require manual login as another user. To do this, either the admins must maintain a list of issued passwords (security risk), or force users to change passwords after they manually overriding the current password via server controls so they can log in. Neither of these solutions are ideal by any measure.

The Proposed Solution: Over lunch, the thought occurred to me that we can find a safe compromise between both views, by creating a fourth kind of user account, which I'll call a hammer for the moment (borrowing from my IRC days). A hammer account would have the following features.

• Can only be created via the server interface.
• Automatically generated username (hammer, followed by 16+ random characters) and very strong password (64+ characters, including letters, numbers, and symbols) - copy and paste from the server terminal is easy, but it would be mathematically impossible to crack it within the account's lifespan.
• Forced maximum lifespan of (two?) hours - plenty of time to perform any necessary action. After the lifespan ends, or after the account is logged out of (whichever happens first), the hammer account is automatically destroyed.
• All hammer actions are attributed to a "System Administrator" bot account, which was automatically created by Phabricator, has no direct login, and cannot be modified or deleted.
• A hammer account has all-access control to everything, regardless of space, scope, view, or edit privileges.
• Optional localhost access only setting could prevent hammer logins from any IP besides localhost, adding a layer of steel to the security of the feature.

Other Benefits: Another benefit of having a hammer account feature is that it would further discourage less-experienced admins from doing unsafe things, like deleting or blowing policy wide open on something the admin wants to edit or remove. The fact they can "hammer-up" and use Phabricator's usual web interface will encourage them to use the typical edit and hide features.

Also, since actions are taking place via the normal Phabricator interface, and are being attributed to System Administrator, admin actions are completely transparent and, in many cases, reversible by the user in question.