-
Type:
MMF
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Labels:
-
Epic Link:
With the introduction of the organizations in SQ, the "Administer System" must be split to cover two use cases which used to be equivalent:
- permission to do anything in a given organization (ie. the god user of a given organization)
- permission to do anything in any organization (ie. the god user on the system as root is on Linux systems)
"Administer System" is really "Administer Organization"
The first use case will be naturally covered by the scoping of all permissions to a given organization (the default organization when migrating to SQ 6.2 or on first install), see MMF-463.
"Administer system" permission will just have to be renamed in all it's references in the UI and the WebService documentation (TODO check with Ann Campbell what new name could be found that would work as well on single organisation instances as on SQ.com).
The permission's key ("admin") can't be renamed as it is used in WebService.
Root
The second use case must be covered by a new mechanism orthogonal to permissions (because they can't apply to more than one organization). This could be a flag on the user.
There is no constraint on the number of root users on SQ.
Some pages/WS which currently requires "Administer System" permission actually require root and only root:
- update center and all Plugin related WS
- system page and all related WS (restart, logs, ...)
- create organisation WS
- system settings (email, public URL, ...) must be edited only by root
New Web Services must be added to add or remove the root privilege on a user. Such WS require to be root. These WS will use a new specific domain (eg. /api/root/*) and be internal.
(side note: a specific domain will allow easy securing of the WS URLs with proxy/firewall configuration).
The WebService to remove the root privilege must enforce that there's always at least one root at anytime.
Seamless implementation
In 6.2, the concept of "root" must not be visible to the user yet.
To this purpose:
The "Administer System" permission won't be visibly renamed to "Administer Organization" as part of this MMF but will be considered as such under the hood (see MMF-483).
setting/removing "Administer System" of the default organization must also set/unset the user as root
- when directly adding/removing the permission to a user
- when adding the permission to a group (all users in the group must be set root)
- when removing the permission from a group (all users in the group must be unset root unless they have the "Administer System" permission by some other mean)
- when adding a user to a group with the permission (the user must be set root)
- when removing a user from a group with the permission (the user must be unset root unless she has the "Administer System" permission by some other mean)
when migrating to SQ 6.2, all users with permission "Administer System" (either directly or though a group) must be given the root privilege.
- since they all will belong to the default organization, it will work
Pages which are actually specific to root will be changed only in MMF-483
- breaks down into
-
SONAR-8190 Add internal WS /api/roots/set_root
-
- Closed
-
-
SONAR-8191 Add internal WS /api/roots/unset_root
-
- Closed
-
-
SONAR-8206 Add internal WS /api/roots/search
-
- Closed
-
-
SONAR-8155 Add root flag on user
-
- Closed
-
-
SONAR-8154 Make WS /api/organizations/create require root
-
- Closed
-
-
SONAR-8156 Migrate all users with permission "Administer System" to root
-
- Closed
-
-
SONAR-8192 Add/remove "Administer System" permission of default organization must set/unset users as root
-
- Closed
-
-
SONAR-8193 Make WS /api/system/* require root
-
- Closed
-
-
SONAR-8194 Make WS /api/plugins/* require root
-
- Closed
-
- depends upon
-
MMF-463 Introduce new "Organization" concept in SonarQube
-
- Closed
-
- is depended upon by
-
MMF-483 Publicly visible support of root users
-
- Closed
-