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 > <https://github.com/jenkinsci/jep/tree/master/jep/223> and JEP-0000 : > System read permission > <https://github.com/timja/jep/tree/jep-system-read/jep/0000> 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). > > - > - 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. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ac92a7af-c1db-4784-bc8f-4d6507414755%40googlegroups.com.
