Page MenuHomePhabricator

Control access to administrator capabilities with custom policies
Closed, ResolvedPublic

Description

It would be nice to eventually provide policies for "Create New Users", "Edit Applications" (probably both globally and per-application) and other powers that are reserved for administrators by default.

This would allow deputizing semi-admins who could perform various administrative tasks without being able to, e.g., change installed applications or create any real mess.


Original Description

I set the "Create New Users" policy to "Members of #access". A member of the access project reported that they are getting a 403/when trying to access /people/create/.

On my Dev box, I could easily reproduce by setting the policy to "All Users".

Event Timeline

joshuaspence raised the priority of this task from to Needs Triage.
joshuaspence updated the task description. (Show Details)
joshuaspence added projects: People, Policy.
joshuaspence added a subscriber: joshuaspence.

See some discussion in D13777.

There is no "Create New Users" policy. The "Can Create (non-bot) Users" policy only controls access to the ability to create standard user accounts, given that you can already create new users. The only meaningful settings for this are "Administrators", "No One", or some subset of administrators.

We added this policy when building the Phacility cluster to prevent instances from adding new un-linked accounts (it is locked to "No One" in the cluster). Realistically, this feature probably only makes sense in the cluster, but it seemed like a small and quasi-general enough thing to add to the upstream that it was reasonable, even though it really just enables Phacility clustering.

I'd eventually like to fully modularize administrator capabilities and give them the current capabilities as defaults, but allow you to change them (for example: let you set the policy for who can edit an application to some other set of users). However, this is a lot of work.

epriestley renamed this task from "Create New Users" policy does not work to Administrator capabilities are not customizable.Aug 3 2015, 1:20 PM
epriestley renamed this task from Administrator capabilities are not customizable to Control access to administrator capabilities with custom policies.
epriestley triaged this task as Low priority.
epriestley updated the task description. (Show Details)
epriestley added a subscriber: chad.
eadler moved this task from Backlog to Nice To Have on the FreeBSD board.
urzds added a subscriber: urzds.Jul 12 2017, 11:14 AM
jcox awarded a token.Jul 24 2017, 11:34 AM
jcox added a subscriber: jcox.
epriestley closed this task as Resolved.Aug 27 2018, 6:43 PM
epriestley claimed this task.

"Disable User", specifically, is now granular.

For other settings we mostly lack use cases.

"Create New Users" is a junk policy per above and maybe going away in T13156, but T5953 may revive it in some sense.

This isn't really "resolved" exactly but there's no outstanding mana behind an arbitrary setting for "Create Users" (outside of T5953) or making other administrative policies more granular, and this task doesn't have any special information about use cases.

"Disable User", specifically, is now granular.

@epriestley: This might add unwanted code complexity, but has it been considered not to allow a user with Disable User rights to disable admin accounts if the user is not admin themselves? Imagine an attacker taking over an account with Disable User rights and then disabling (locking out) all other accounts with such rights, until someone with shell access can be reached.

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.