Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66382

Job - Delete permission at Jenkins root level is needed to shelve the project

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: shelve-project-plugin
    • Labels:
      None
    • Environment:
      * Jenkins 2.289.3
      * Shelve Project Plugin 3.2
    • Similar Issues:

      Description

      In the following scenario:

      • Choose `Project-based Matrix Authorization Strategy` Athorization strategy (and other like Role-Base strategy)
      • `user1` without the `job - delete` permission at the Jenkins root level.
      • `user1` with `job - delete` permission at the project (pipeline) level.

      The user is able to see the `delete project` link but not the `shelve project` link.

       

       

      Reviewing the source code, I found the following line:

       

      I believe the item that is currently visited should be checked and not the `Jenkins.getInstance()` item.

      This problem force us to grant job - deleting permission for all project if we want to shelve only one project.

        Attachments

        1. Assign Roles [Jenkins] — Mozilla Firefox_215.png
          297 kB
          Ignacio Roncero Bazarra
        2. Configure Global Security [Jenkins] — Mozilla Firefox_220.png
          274 kB
          Ignacio Roncero Bazarra
        3. Configure Global Security [Jenkins] — Mozilla Firefox_221.png
          305 kB
          Ignacio Roncero Bazarra
        4. freestyle [folder1] [Jenkins] - Google Chrome_218.png
          184 kB
          Ignacio Roncero Bazarra
        5. freestyle [folder1] [Jenkins] - Google Chrome_224.png
          195 kB
          Ignacio Roncero Bazarra
        6. freestyle [folder1] [Jenkins] — Mozilla Firefox (Private Browsing)_216.png
          186 kB
          Ignacio Roncero Bazarra
        7. freestyle [folder1] [Jenkins] — Mozilla Firefox (Private Browsing)_226.png
          197 kB
          Ignacio Roncero Bazarra
        8. freestyle Config [Jenkins] — Mozilla Firefox_222.png
          290 kB
          Ignacio Roncero Bazarra
        9. Manage Roles [Jenkins] — Mozilla Firefox_214.png
          329 kB
          Ignacio Roncero Bazarra
        10. pipeline [folder1] [Jenkins] - Google Chrome_219.png
          201 kB
          Ignacio Roncero Bazarra
        11. pipeline [folder1] [Jenkins] - Google Chrome_225.png
          213 kB
          Ignacio Roncero Bazarra
        12. pipeline [folder1] [Jenkins] — Mozilla Firefox (Private Browsing)_217.png
          217 kB
          Ignacio Roncero Bazarra
        13. pipeline [folder1] [Jenkins] — Mozilla Firefox (Private Browsing)_227.png
          203 kB
          Ignacio Roncero Bazarra
        14. pipeline Config [Jenkins] — Mozilla Firefox_223.png
          293 kB
          Ignacio Roncero Bazarra
        15. Selection_203.png
          109 kB
          Ignacio Roncero Bazarra
        16. Selection_204.png
          109 kB
          Ignacio Roncero Bazarra
        17. Selection_205.png
          57 kB
          Ignacio Roncero Bazarra
        18. Selection_206.png
          139 kB
          Ignacio Roncero Bazarra

          Activity

          Hide
          pierrebtz Pierre Beitz added a comment -

          Ignacio Roncero Bazarra while not ideal, this is currently done so by design for simplicity sake when developing JENKINS-27734 (which introduced the possibility to shelve any kind of item, including containers (eg folder)).

          The issue with what you are proposing is that it would rely on the authorization scheme to inherit rights to children items which is not necessarily true, eg with the Project-based Matrix Authorization Strategy, one strategy is:

          Do not inherit permissions: The most restrictive inheritance configuration. Only permissions defined explicitly on this agent or item will be granted. The only exception is Overall/Administer: It is not possible to remove access to an agent or item from Jenkins administrators.

          What this means is that you can have delete permission on an item, yet not have it on a child item. I'm not sure how Jenkins reconcile this, I'll need to mount a test environment and run some tests to understand the behavior of the delete action in Jenkins.

          Show
          pierrebtz Pierre Beitz added a comment - Ignacio Roncero Bazarra  while not ideal, this is currently done so by design for simplicity sake when developing  JENKINS-27734  (which introduced the possibility to shelve any kind of item, including containers (eg folder)). The issue with what you are proposing is that it would rely on the authorization scheme to inherit rights to children items which is not necessarily true, eg with the Project-based Matrix Authorization Strategy, one strategy is: Do not inherit permissions: The most restrictive inheritance configuration. Only permissions defined explicitly on this agent or item will be granted. The only exception is Overall/Administer: It is not possible to remove access to an agent or item from Jenkins administrators. What this means is that you can have delete permission on an item, yet not have it on a child item. I'm not sure how Jenkins reconcile this, I'll need to mount a test environment and run some tests to understand the behavior of the delete action in Jenkins.
          Hide
          ironcerocloudbees Ignacio Roncero Bazarra added a comment -

          Hi Pierre Beitz,

          Thank you for reviewing the case so quickly.

          I'm not sure if I understood correctly your concerns. I've been working on testing the inheriting and this is what I found:

          I spawned four Jenkins instances with `Root Level User` (the user with delete permission at the root level) and `Project Level User` (the user with delete permission at the project level, when it is possible) and with two projects inside a folder:

          1. Using `Logged In Users Can Do Anything`: In this case, any user can do anything and, obviously, both `Root Level User` and `Project Level User` users can shelve the projects.
          2. Using `Matrix Based Security`: In this case, it is not possible to grant permission at the project level only. So, only by granting delete permission at the root level, we can shelve those projects.
          3. Using `Project Based Matrix Authorization Strategy`:  The `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them.
          4. Using `Role Based Strategy`: Again, the `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them.

          I will try to make a pull request to explain better what I am trying to explain.

          Kind regards.

          Show
          ironcerocloudbees Ignacio Roncero Bazarra added a comment - Hi Pierre Beitz , Thank you for reviewing the case so quickly. I'm not sure if I understood correctly your concerns. I've been working on testing the inheriting and this is what I found: I spawned four Jenkins instances with `Root Level User` (the user with delete permission at the root level) and `Project Level User` (the user with delete permission at the project level, when it is possible) and with two projects inside a folder: Using `Logged In Users Can Do Anything`: In this case, any user can do anything and, obviously, both `Root Level User` and `Project Level User` users can shelve the projects. Using `Matrix Based Security`: In this case, it is not possible to grant permission at the project level only. So, only by granting delete permission at the root level, we can shelve those projects. Using `Project Based Matrix Authorization Strategy`:  The `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them. Using `Role Based Strategy`: Again, the `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them. I will try to make a pull request to explain better what I am trying to explain. Kind regards.
          Hide
          pierrebtz Pierre Beitz added a comment -

          Ignacio Roncero Bazarra I opened https://issues.jenkins.io/browse/JENKINS-66419 that gives details about the situation I was mentioning. What I described for the delete action is transposable to the shelve one.

          Show
          pierrebtz Pierre Beitz added a comment - Ignacio Roncero Bazarra  I opened https://issues.jenkins.io/browse/JENKINS-66419  that gives details about the situation I was mentioning. What I described for the delete action is transposable to the shelve one.

            People

            Assignee:
            pierrebtz Pierre Beitz
            Reporter:
            ironcerocloudbees Ignacio Roncero Bazarra
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: