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

Naginator plugin uses user credentials of failed run

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When pressing Re-try after failed build, Naginator plugin is using user credentials of previous failed build. Username can belong to another user. This feature makes it possible to bypass the user authorization rules. Could this plug-in feature to change? It would be better to use current user (who is pressing Re-try button) credentials in Re-try feature by default (for example having global config checkbox settings for this).

        Attachments

          Activity

          algronlu Aleksi Grönlund created issue -
          algronlu Aleksi Grönlund made changes -
          Field Original Value New Value
          Description We are using Jenkins to deploy applications. Application deployment logic is defined in template item (template-project-plugin used). This login also contains security authorization rules based on username. Different users having deployment rights to different environments.

          When pressing Re-try after failed build, Naginator plugin is using user credentials of previous failed build. Those could be credentials of another user. With this feature it is possible to overtake user security authorization rules. This is causing security problems. Would it be possible to change this feature in Naginator? It would be better to use current user credentials in Re-try by default (for example having global config checkbox settings for this).
          When pressing Re-try after failed build, Naginator plugin is using user credentials of that previous failed build. Those could be credentials of another user. With this feature it is possible to overtake user security authorization rules. This is causing security problems. Would it be possible to change this feature in Naginator? It would be better to use current user (who is pressing Re-try button) credentials in Re-try by default (for example having global config checkbox settings for this).
          algronlu Aleksi Grönlund made changes -
          Description When pressing Re-try after failed build, Naginator plugin is using user credentials of that previous failed build. Those could be credentials of another user. With this feature it is possible to overtake user security authorization rules. This is causing security problems. Would it be possible to change this feature in Naginator? It would be better to use current user (who is pressing Re-try button) credentials in Re-try by default (for example having global config checkbox settings for this). When pressing Re-try after failed build, Naginator plugin is using user credentials of previous failed build. Username can belong to another user. This feature makes it possible to bypass the user authorization rules. Could this plug-in feature to change? It would be better to use current user (who is pressing Re-try button) credentials in Re-try feature by default (for example having global config checkbox settings for this).
          algronlu Aleksi Grönlund made changes -
          Component/s template-project-plugin [ 15623 ]
          Hide
          ikedam ikedam added a comment -

          I want to know what credentials you exactly mean (credentials plugin?)
          Would you tell me some scenarios that can cause security issues?

          Show
          ikedam ikedam added a comment - I want to know what credentials you exactly mean (credentials plugin?) Would you tell me some scenarios that can cause security issues?
          ikedam ikedam made changes -
          Assignee Nicolas De Loof [ ndeloof ] Aleksi Grönlund [ algronlu ]
          Hide
          algronlu Aleksi Grönlund added a comment -

          How to reproduce this:
          1. Login to Jenkins with "user1"
          2. Execute item "xyz", and make sure that item is failing
          3. Logout from Jenkins
          4. Login to Jenkins with "user2"
          5. Navigate to item "xyz" and select Re-try
          6. Check from console log who started item "xyz"? I found from console log that this is "user1" even Re-try is selected by "user2"

          Show
          algronlu Aleksi Grönlund added a comment - How to reproduce this: 1. Login to Jenkins with "user1" 2. Execute item "xyz", and make sure that item is failing 3. Logout from Jenkins 4. Login to Jenkins with "user2" 5. Navigate to item "xyz" and select Re-try 6. Check from console log who started item "xyz"? I found from console log that this is "user1" even Re-try is selected by "user2"
          Hide
          ikedam ikedam added a comment - - edited

          Is the issue is resolved if the console log is output as "started by user1 (replayed as by user2)"?

          Show
          ikedam ikedam added a comment - - edited Is the issue is resolved if the console log is output as "started by user1 (replayed as by user2)"?
          algronlu Aleksi Grönlund made changes -
          Component/s build-user-vars-plugin [ 17477 ]
          Hide
          algronlu Aleksi Grönlund added a comment -

          We are using build-user-vars-plugin to check who is running (variable = BUILD_USER_ID) currently that build:
          https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin

          I think that in re-try situation build-user-vars-plugin (all variables from this plugin) should give "user2" information who actually selected Re-try button.

          Show
          algronlu Aleksi Grönlund added a comment - We are using build-user-vars-plugin to check who is running (variable = BUILD_USER_ID) currently that build: https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin I think that in re-try situation build-user-vars-plugin (all variables from this plugin) should give "user2" information who actually selected Re-try button.
          Hide
          ikedam ikedam added a comment -

          I can't get your actual problem.
          In some situations users may want fo replay the build including the value of BUILD_USER_ID.
          If it causes security issues, users can disable the replay feature for the project by checking "Don't let user manually re-trigger this job". (In that case, automatic retriggering of failed builds is enabled).
          Let me know more details about your problem.

          Show
          ikedam ikedam added a comment - I can't get your actual problem. In some situations users may want fo replay the build including the value of BUILD_USER_ID. If it causes security issues, users can disable the replay feature for the project by checking "Don't let user manually re-trigger this job". (In that case, automatic retriggering of failed builds is enabled). Let me know more details about your problem.
          Hide
          algronlu Aleksi Grönlund added a comment -

          Would it be possible to add configuration setting (checkbox) in Jenkin global configuration where it is possible to select which user is used in replay (default settings for this): Current user or that previous user ?

          Show
          algronlu Aleksi Grönlund added a comment - Would it be possible to add configuration setting (checkbox) in Jenkin global configuration where it is possible to select which user is used in replay (default settings for this): Current user or that previous user ?
          Hide
          ikedam ikedam added a comment -

          No, I don't plan for that for now.
          Please let me know why that feature is useful.
          Users can trigger a new build
          if they need a build run with their own ID, can't they?
          Let me know why you want to use the retrying feature.

          Talking about "bypassing the user authorization rules", it might make sense to introduce "Don't let user manually re-trigger this job" as a global configuration.

          Show
          ikedam ikedam added a comment - No, I don't plan for that for now. Please let me know why that feature is useful. Users can trigger a new build if they need a build run with their own ID, can't they? Let me know why you want to use the retrying feature. Talking about "bypassing the user authorization rules", it might make sense to introduce "Don't let user manually re-trigger this job" as a global configuration.
          Hide
          algronlu Aleksi Grönlund added a comment -

          It would be good to make sure somehow (force this for all users in global configuration ?) that there is no possibility for user to re-trigger failed run with another username. This is useful when item contains some authorization rules based on BUILD_USER_ID value.

          Show
          algronlu Aleksi Grönlund added a comment - It would be good to make sure somehow (force this for all users in global configuration ?) that there is no possibility for user to re-trigger failed run with another username. This is useful when item contains some authorization rules based on BUILD_USER_ID value.
          Hide
          ikedam ikedam added a comment -

          It might be useful for some situations, but it's not a bug.

          Show
          ikedam ikedam added a comment - It might be useful for some situations, but it's not a bug.
          ikedam ikedam made changes -
          Resolution Not A Defect [ 7 ]
          Status Open [ 1 ] Resolved [ 5 ]

            People

            Assignee:
            algronlu Aleksi Grönlund
            Reporter:
            algronlu Aleksi Grönlund
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: