JEP |
224 |
|---|---|
Title |
Readonly system configuration |
Sponsor |
|
Status |
Final 🔒 |
Type |
Standards |
Created |
2020-01-20 |
BDFL-Delegate |
|
JIRA |
Any methods that check for Jenkins.ADMINISTER, Jenkins.RUN_SCRIPTS, PluginManager.CONFIGURE_UPDATECENTER, and PluginManager.UPLOAD_PLUGINS will be evaluated to determine if the use of the new Jenkins.SYSTEM_READ permission type is appropriate.
The general rule of thumb is that all views should be readable by Jenkins.SYSTEM_READ, unless they give no benefit to the user.
An example of a non beneficial view is the 'Script console' view, this is too dangerous for non administrators,
and there is no useful information on here so the permissions on this view won’t be changed.
By default, all of the configuration sections in the /manage page require Jenkins.ADMINISTER, this will be changed to Jenkins.SYSTEM_READ. This is safe as plugins will have additional permission checks on Jenkins.ADMINISTER on form submission, to prevent existing CSRF attacks.
If a plugin doesn’t want Jenkins.SYSTEM_READ users to show up on /manage configuration section
they simply need to override ManagementLink.getRequiredPermission() to return Jenkins.ADMINISTER.
For example :
public class CustomLink extends ManagementLink {
@Override
public Permission getRequiredPermission() {
return Jenkins.ADMINSTER;
}
}Most configuration links are fully available for users with Jenkins.SYSTEM_READ with the following exceptions:
-
Script Console - this allows escalating to full system access and gives no benefit to a read only user.
-
Reload Configuration from Disk - this is only useful if you can change the configuration.
Many views have been modified to hide information that is not relevent to read only users.
Jelly tags in the Jenkins core have been modified to display a read only state, i.e. text instead of inputs,
icons for checkboxes. Any plain html tags need to be updated separately and each page that wants to use
Jenkins.SYSTEM_READ needs to add a little bit of code to activate it:
Jelly
<j:set var="displayOnlyMode" value="${!app.hasPermission(app.ADMINISTER)}" />Groovy
if (!h.hasPermission(app.ADMINISTER)) {
set("displayOnlyMode", "true")
}At a minimum, submit / apply buttons have been hidden on every view that has been found to be now
visible to Jenkins.SYSTEM_READ users.
Other examples:
-
Allowing users to view
Log Recordersthat have been pre-configured by an Admin or something like 'JCasc' -
Removing the 'Downgrade to <version>' plugin button.
-
Removing some 'Validate connection' buttons.
The code required for hiding parts of the UI is:
Jelly
<j:jelly xmlns:l="/lib/layout">
<l:hasPermission permission="${app.ADMINISTER}">
...
</l:hasPermission>
</j:jelly>Groovy
def l=namespace(lib.LayoutTagLib)
l.hasPermission(permission: app.ADMINISTER) {
}Jenkins requires full administrator access to view any of it’s configuration, logs and monitoring information.
There is a number of reasons to allow non administrative read access:
-
Given the rise of the configuration-as-code plugin a lot of Jenkins instances are fully managed as code, no changes are allowed through the UI. The problem with this is you don’t know when new plugin versions are available and in order to see what other configuration options are available to a plugin you currently need
Jenkins.ADMINISTER. -
Allowing non administrator users to debug issues with their builds easier, i.e. given a 'Jenkins' error message in a build the user can check, 1. which plugins are installed, 2. the version of the plugin. This can allow the user to solve their issue themselves and makes it easier for the user to report an issue with a plugin directly to the maintainers.
This JEP does not propose a feature that puts Jenkins into a 'read only mode'. It would be possible to do this
by giving out the Jenkins.SYSTEM_READ permission, or how it is done today by not giving out Jenkins.ADMINISTER at all.
Instead this JEP proposes a permission that could be given to all or a subset of users that gives them near global read of system configuration.
This feature will be disabled by default for a few reasons:
-
there will likely need to be changes across plugins, it will give a better user experience if those plugins are released before this is enabled by default.
-
there is a risk that some plugins don’t do the correct permissions checks and modification to data is possible when pages can be viewed, if an administrator chooses to enable this feature they can weigh up the risks, and evaluate based on installed plugins.
-
to give more time to enhance the user experience and allow delivering this JEP across multiple pull requests / Jenkins releases.
The feature will be enabled by either:
-
installing the extended-read-permission plugin.
-
setting a system property.
The extended-read-permission plugin has been extended to allow plugins to use the new permission without having to bump the core version significantly.
A conservative approach has been taken when granting access to views.
An example being administrative monitors, lots of them have side affects when loaded, and have added their on views, including some in plugins. Currently the check for administrative monitors 'Administer' permission is done centrally in core. If this were to be relaxed then all views would also become accessible, this is not a change that can be done easily without co-ordinating changes across plugins.