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

          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: