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

    • Bug
    • Status: In Progress (View Workflow)
    • Minor
    • Resolution: Unresolved
    • shelve-project-plugin
    • None
    • * Jenkins 2.289.3
      * Shelve Project Plugin 3.2

    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

          pierrebtz Pierre Beitz added a comment -

          ironcerocloudbees 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.

          pierrebtz Pierre Beitz added a comment - ironcerocloudbees  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.

          Hi pierrebtz,

          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.

          ironcerocloudbees Ignacio Roncero Bazarra added a comment - Hi pierrebtz , 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.
          pierrebtz Pierre Beitz added a comment -

          ironcerocloudbees 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.

          pierrebtz Pierre Beitz added a comment - ironcerocloudbees  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.
          akmjenkins ASHOK MOHANTY added a comment -

          I am not able to open JENKINS-66419..
          Regarding the job deletion we are also facing the issue. Example..
          job1 – 'jenkins/job/HGxx_Goyy/job/haven/job/test_pipeline'.
          user1,user2 has all kind of permission to 'run, create, delete, etc...' for this job (infact have all the permission for the parent folder, 'HGxx_Goyy').
          But when 'user1/2' tries to delete the job '....../test_pipeline' its randomly throws error - permission issue for some other folder 'jenkins/job/HSzx_Clnn'.

          akmjenkins ASHOK MOHANTY added a comment - I am not able to open JENKINS-66419.. Regarding the job deletion we are also facing the issue. Example.. job1 – 'jenkins/job/HGxx_Goyy/job/haven/job/test_pipeline'. user1,user2 has all kind of permission to 'run, create, delete, etc...' for this job (infact have all the permission for the parent folder, 'HGxx_Goyy'). But when 'user1/2' tries to delete the job '....../test_pipeline' its randomly throws error - permission issue for some other folder 'jenkins/job/HSzx_Clnn'.
          pierrebtz Pierre Beitz added a comment -

          > I am not able to open JENKINS-66419..

          It was moved as a security issue so it's expected.

           

          > But when 'user1/2' tries to delete the job '

          I'm unsure I follow, this report is about an issue with the shelving of a job. If the user tries to delete it, it has nothing to do with the shelve project plugin.

          pierrebtz Pierre Beitz added a comment - > I am not able to open JENKINS-66419.. It was moved as a security issue so it's expected.   > But when 'user1/2' tries to delete the job ' I'm unsure I follow, this report is about an issue with the shelving of a job. If the user tries to delete it, it has nothing to do with the shelve project plugin.
          akmjenkins ASHOK MOHANTY added a comment - - edited

          Thanks for the reply. I will create a new one for the second part (delete a job throws error - Access denied to another job).

          akmjenkins ASHOK MOHANTY added a comment - - edited Thanks for the reply. I will create a new one for the second part (delete a job throws error - Access denied to another job).

          People

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

            Dates

              Created:
              Updated: