What is the best approach for mutually exclusive permissions - re: proposed Jenkins.CONFIGURE and Jenkins.SYSTEM_READ permissions

[Michael Cirioli]

(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)

JEP-223 : "Limited Administer" permission and JEP-0000 : System read permission propose introducing new permission types aimed at solving specific problems for a Jenkins administrator.  JEP-223 provides for a new permission that allows an administrator to delegate the ability to configure non-security aspects of a Jenkins instance, while JEP-0000 (System read permission) will allow a non-administrator user to view (but not change) many configuration options that would normally only be visible to a user who has the overall Jenkins.ADMINISTER permission.

Taken individually, either of these proposed changes provides a fairly straightforward user experience.  However, assuming both are eventually accepted, the user experience will not be so clear.  Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be?

• Both proposals expect plugins to override getRequiredPermission() in order to determine what should be shown to a user.  The intention of JEP-0000 is that _most_ items would be shown (read-only) to a user,   This will potentially create a conflict with JEP-223, as a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
• If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ, should they be able to view some things they can't configure, and being able to change some things that a user who only has Jenkins.SYSTEM_READ would normally only be able to view?
  

I don't currently have a proposal on how to best address this, but I do have some ideas....

• Provide a mean for permissions to specify precedence (ie. CONFIGURE is less restrictive than SYSTEM_READ).  This is different than the current implies(...) because an administrator may not want a user with the CONFIGURE permission to automatically also have SYSTEM_READ
• Add logic to the matrix-auth plugin such that some permission types are mutually exclusive.  ie. if you grant CONFIGURE, you can't also grant SYSTEM_READ.
  
• Allow getRequiredPermission() to return a list of permissions, and tailor the user experience for any given plugin with custom logic.  This may be more error prone to maintain, and would need to be well thought out enough so that any plugins that are unaware of the new permissions behave in a predictable way.

Although the above thoughts are focused on the two new permissions currently being proposed, an ideal solution should support any additional permissions that may find their way into Jenkins in the future.

[Jesse Glick]

On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <mcir...@cloudbees.com> wrote:
> Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be?
>

> ..a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes.

If you split parts of the `/configure` page into an `/administer`
page, rather than conditionally hiding them, then I think this could
be solved in a different way that feels more in line with existing
patterns:

· If you have `ADMINISTER`, `/administer` has a *Save* (and *Apply*)
button. Else, if you have `SYSTEM_READ`, it does not. If you have
neither, it cannot be displayed at all.
· If you have `CONFIGURE`, `/configure` has *Save*. If you have
`VIEW_CONFIGURATION` (at global scope?), it does not. If you have
neither, it cannot be displayed at all.

> an ideal solution should support any additional permissions that may find their way into Jenkins in the future

Do we really want to be adding complex new permission options? The
Jenkins permission system is way too complex as it stands, making for
a poor UX, and as for Jenkins developers, I at least can barely keep
the intended behavior straight in my head. Many advanced use cases
would be better handled via `configuration-as-code` plus other
tooling, processes, or policies (GitHub’s `CODEOWNERS`, for example).

[Tim Jacomb]

(replies inline)

On Wed, 22 Jan 2020 at 01:24, Michael Cirioli <mcir...@cloudbees.com> wrote:

(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)

• Both proposals expect plugins to override getRequiredPermission() in order to determine what should be shown to a user.  The intention of JEP-0000 is that _most_ items would be shown (read-only) to a user,   This will potentially create a conflict with JEP-223, as a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
• If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ, should they be able to view some things they can't configure, and being able to change some things that a user who only has Jenkins.SYSTEM_READ would normally only be able to view?
  

I don't currently have a proposal on how to best address this, but I do have some ideas....

• Provide a mean for permissions to specify precedence (ie. CONFIGURE is less restrictive than SYSTEM_READ).  This is different than the current implies(...) because an administrator may not want a user with the CONFIGURE permission to automatically also have SYSTEM_READ

I think that configure should just be above system read, but I don't know how that would affect the UX of CONFIGURE

• Add logic to the matrix-auth plugin such that some permission types are mutually exclusive.  ie. if you grant CONFIGURE, you can't also grant SYSTEM_READ.
  

Hopefully unneeded

• Allow getRequiredPermission() to return a list of permissions, and tailor the user experience for any given plugin with custom logic.  This may be more error prone to maintain, and would need to be well thought out enough so that any plugins that are unaware of the new permissions behave in a predictable way.

Another thought I had was updating the jelly tags to allow to take an array, and add a method called 'hasAnyPermission', which would at least solve the view part 

Although the above thoughts are focused on the two new permissions currently being proposed, an ideal solution should support any additional permissions that may find their way into Jenkins in the future.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com.

On Wed, 22 Jan 2020 at 15:28, Jesse Glick <jgl...@cloudbees.com> wrote:

On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <mcir...@cloudbees.com> wrote:
> Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be?
>
> ..a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes.

If you split parts of the `/configure` page into an `/administer`
page, rather than conditionally hiding them, then I think this could
be solved in a different way that feels more in line with existing
patterns:

I'm not sure this would work well for read only support, what items on the existing configure page would you not want to expose? 

· If you have `ADMINISTER`, `/administer` has a *Save* (and *Apply*)
button. Else, if you have `SYSTEM_READ`, it does not. If you have
neither, it cannot be displayed at all.
· If you have `CONFIGURE`, `/configure` has *Save*. If you have
`VIEW_CONFIGURATION` (at global scope?), it does not. If you have
neither, it cannot be displayed at all. 

> an ideal solution should support any additional permissions that may find their way into Jenkins in the future

Do we really want to be adding complex new permission options? The
Jenkins permission system is way too complex as it stands, making for
a poor UX, and as for Jenkins developers, I at least can barely keep
the intended behavior straight in my head. Many advanced use cases
would be better handled via `configuration-as-code` plus other
tooling, processes, or policies (GitHub’s `CODEOWNERS`, for example).

Absolutely agree with handling configuration via `configuration-as-code` or other tools, but I do think we're missing a lot of information that is useful to users

to either:

1. contribute to the plugins / configuration of their instance.

2. debug why their build has an issue

3. debug / solve an issue faster with why their agent isn't starting (cloud logs, agent startup logs etc)

Just thinking of ci.jenkins.io if some of the information above were surfaced to a wider audience I believe we would be able to have a more stable CI instance / information available far quicker

Many thanks for all feedback

Tim

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1fvvuZiiHRNH7mD6kPMV%3DtuC1EJPb3x8r71SmwR%3DK1kw%40mail.gmail.com.

[James Nord]

On Wednesday, January 22, 2020 at 1:24:05 AM UTC, Michael Cirioli wrote:

(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)

JEP-223 : "Limited Administer" permission and JEP-0000 : System read permission propose introducing new permission types aimed at solving specific problems for a Jenkins administrator.  JEP-223 provides for a new permission that allows an administrator to delegate the ability to configure non-security aspects of a Jenkins instance, while JEP-0000 (System read permission) will allow a non-administrator user to view (but not change) many configuration options that would normally only be visible to a user who has the overall Jenkins.ADMINISTER permission.

Taken individually, either of these proposed changes provides a fairly straightforward user experience.  However, assuming both are eventually accepted, the user experience will not be so clear.  Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be?

• Both proposals expect plugins to override getRequiredPermission() in order to determine what should be shown to a user. 

I think I am missing something and probably need to read the JEP but why would you need to override getRequiredPermission for SYSTEM_READ.  the idea is you can read everything everywhere...  so you have no permission check - but you would not make anything editable unless you had some other WRITE PERMISSION (how is this different from having SYSTEM_READ and having two jobs (one which also grants you ITEM.CONFIGURE and one which does only grants not - thus you should have ITEM.READ?).  

• The intention of JEP-0000 is that _most_ items would be shown (read-only) to a user,   This will potentially create a conflict with JEP-223, as a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes. 

• If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ,

 

• should they be able to view some things they can't configure,

yes 

• and being able to change some things that a user who only has Jenkins.SYSTEM_READ would normally only be able to view?
  

no - that would be a big UX issue if not a security issue (the joining of 2 permission should not bive you greater powers than the sum of their individual parts).

I don't currently have a proposal on how to best address this, but I do have some ideas....

• Provide a mean for permissions to specify precedence (ie. CONFIGURE is less restrictive than SYSTEM_READ).  This is different than the current implies(...) because an administrator may not want a user with the CONFIGURE permission to automatically also have SYSTEM_READ
• Add logic to the matrix-auth plugin such that some permission types are mutually exclusive.  ie. if you grant CONFIGURE, you can't also grant SYSTEM_READ.
  

probably an absolute UX nightmare as you can only resolve this at call time (not in the configuration).

[Michael Cirioli]

Tim,

I've added a section to our proposed JEP-223 committing to work with you on the Jenkins.SYSTEM_READ effort so that we can find a way to provide both of these features to the user in a way that makes sense and provides a non-confusing experience.

thanks

-mike

On Thursday, January 23, 2020 at 2:57:00 PM UTC-5, Tim Jacomb wrote:

(replies inline)

On Wed, 22 Jan 2020 at 01:24, Michael Cirioli <mcir...@cloudbees.com> wrote:

(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)

• Both proposals expect plugins to override getRequiredPermission() in order to determine what should be shown to a user.  The intention of JEP-0000 is that _most_ items would be shown (read-only) to a user,   This will potentially create a conflict with JEP-223, as a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
• If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ, should they be able to view some things they can't configure, and being able to change some things that a user who only has Jenkins.SYSTEM_READ would normally only be able to view?
  

I don't currently have a proposal on how to best address this, but I do have some ideas....

• Provide a mean for permissions to specify precedence (ie. CONFIGURE is less restrictive than SYSTEM_READ).  This is different than the current implies(...) because an administrator may not want a user with the CONFIGURE permission to automatically also have SYSTEM_READ

I think that configure should just be above system read, but I don't know how that would affect the UX of CONFIGURE

• Add logic to the matrix-auth plugin such that some permission types are mutually exclusive.  ie. if you grant CONFIGURE, you can't also grant SYSTEM_READ.
  

Hopefully unneeded

• Allow getRequiredPermission() to return a list of permissions, and tailor the user experience for any given plugin with custom logic.  This may be more error prone to maintain, and would need to be well thought out enough so that any plugins that are unaware of the new permissions behave in a predictable way.

Another thought I had was updating the jelly tags to allow to take an array, and add a method called 'hasAnyPermission', which would at least solve the view part 

Although the above thoughts are focused on the two new permissions currently being proposed, an ideal solution should support any additional permissions that may find their way into Jenkins in the future.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Tim Jacomb]

Perfect thanks Michael

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/81fe1458-9660-4dd5-a538-f0f720708b45%40googlegroups.com.

[Tim Jacomb]

An update on system read,

Wadeck and I took a look at making the UI look read only, rather than just removing the apply buttons, and we got it working.

Screenshots are in the PR description:

https://github.com/jenkinsci/jenkins/pull/4149

Please take a look and provide any feedback you have

Thank

Tim