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

Input step submitter parameter is ignored for administrators

    XMLWordPrintable

Details

    • Bug
    • Status: Fixed but Unreleased (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • Jenkins 2.151.0
      Pipeline Input Step: 2.9

    Description

      I use the following snippet in my DSL pipeline

      operators = "ldapUserGroup"
      ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
      returnValue = input message: 'DEPLOY ?', 
                          parameters: [choice], 
                          submitter: operators, 
                          submitterParameter: 'approver'
      

      I am not part of the ldapUserGroup thus I would expect the pipeline not to continue. However the pipeline continues anyway.

      07:39:05 Approved by Surname Lastname
      [Pipeline] }
      

      The same happens if i use a particular userID or list of userIDs rather than an ldapGroup

      operators = "userID0001,userID0002"
      ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
      returnValue = input message: 'DEPLOY ?', 
                          parameters: [choice], 
                          submitter: operators, 
                          submitterParameter: 'approver'
      

      Attachments

        Issue Links

          Activity

            papanito papanito created issue -
            papanito papanito made changes -
            Field Original Value New Value
            Description I use the following snippet in my DSL pipeline

             
            {code:java}
            operators = "ldapUserGroup"
            ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
            returnValue = input message: 'DEPLOY ?',
                                parameters: [choice],
                                submitter: operators,
                                submitterParameter: 'approver'
            {code}
            I am not part of the {{ldapUserGroup}} thus I would expect the pipeline not to continue. However the pipeline continues anyway.

             

             
            {code:java}
            07:39:05 Approved by Surname Lastname
            [Pipeline] }
            {code}
             

            The same happens if i use a particular userID or list of userIDs rather than an ldapGroup
            {code:java}
            operators = "userID0001,userID0002"
            ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
            returnValue = input message: 'DEPLOY ?',
                                parameters: [choice],
                                submitter: operators,
                                submitterParameter: 'approver'
            {code}
            I use the following snippet in my DSL pipeline
            {code:java}
            operators = "ldapUserGroup"
            ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
            returnValue = input message: 'DEPLOY ?',
                                parameters: [choice],
                                submitter: operators,
                                submitterParameter: 'approver'
            {code}
            I am not part of the {{ldapUserGroup}} thus I would expect the pipeline not to continue. However the pipeline continues anyway.
            {code:java}
            07:39:05 Approved by Surname Lastname
            [Pipeline] }
            {code}
            The same happens if i use a particular userID or list of userIDs rather than an ldapGroup
            {code:java}
            operators = "userID0001,userID0002"
            ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
            returnValue = input message: 'DEPLOY ?',
                                parameters: [choice],
                                submitter: operators,
                                submitterParameter: 'approver'
            {code}
            papanito papanito added a comment -

            Apparently, me as an administrator can answer the question. Other users, which are not administrator are rejected when answering the question.

            Is this the expected behaviour? If yes, I did not see this in the documentation, thus it would be good to mention this behaviour.

            papanito papanito added a comment - Apparently, me as an administrator can answer the question. Other users, which are not administrator are rejected when answering the question. Is this the expected behaviour? If yes, I did not see this in the documentation, thus it would be good to mention this behaviour.
            orathore Omit Rathore added a comment - - edited

            This is very dangerous issue , team relying on permissions control with submitter is broken. We had to revert to 2.8 .

             Ideal flow would be only user/team mentioned as submitter should be allowed to proceed.It is classical example of privilege escalation. It is kind of security threat.

            It's fine to have these feature if submitter is not mentioned.

            orathore Omit Rathore added a comment - - edited This is very dangerous issue , team relying on permissions control with submitter is broken. We had to revert to 2.8 .  Ideal flow would be only user/team mentioned as submitter should be allowed to proceed.It is classical example of privilege escalation. It is kind of security threat. It's fine to have these feature if submitter is not mentioned.

            It seems that's the expected behavior due to https://issues.jenkins-ci.org/browse/JENKINS-48998. If you're an admin, you bypass the regular check of submitter user/group.

            svanoort could you confirm?

            wfollonier Wadeck Follonier added a comment - It seems that's the expected behavior due to https://issues.jenkins-ci.org/browse/JENKINS-48998 . If you're an admin, you bypass the regular check of submitter user/group. svanoort could you confirm?
            dnusbaum Devin Nusbaum added a comment -

            wfollonier Yes, based on JENKINS-48998 it looks like it is expected that an admin can approve any input step, and this makes sense because an admin could do this anyway by rewriting the Pipeline, and if they have RUN_SCRIPTS permission as well, directly approve it via the script console or other tricky things.

            I guess we could update help-submitter.html to mention this explicitly.

            dnusbaum Devin Nusbaum added a comment - wfollonier Yes, based on JENKINS-48998 it looks like it is expected that an admin can approve any input step, and this makes sense because an admin could do this anyway by rewriting the Pipeline, and if they have RUN_SCRIPTS permission as well, directly approve it via the script console or other tricky things. I guess we could update help-submitter.html to mention this explicitly.
            papanito papanito added a comment - I've created a pull request: https://github.com/jenkinsci/pipeline-input-step-plugin/pull/39
            orathore Omit Rathore added a comment -

            Is there any use case where user is not an Admin  also not in submitter can still approve input step.

             

            orathore Omit Rathore added a comment - Is there any use case where user is not an Admin  also not in submitter can still approve input step.  
            dnusbaum Devin Nusbaum made changes -
            Summary Input Submitter parameter ignored Input step submitter parameter is ignored for administrators
            dnusbaum Devin Nusbaum made changes -
            Remote Link This issue links to "jenkinsci/pipeline-input-step-plugin#39 (Web Link)" [ 23601 ]
            dnusbaum Devin Nusbaum made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            dnusbaum Devin Nusbaum made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            dnusbaum Devin Nusbaum added a comment -

            orathore I don't think so, if you think you have found such a case, and can reproduce it, please file a new issue in the SECURITY project and CC me on it.

            dnusbaum Devin Nusbaum added a comment - orathore I don't think so, if you think you have found such a case, and can reproduce it, please file a new issue in the SECURITY project and CC me on it.
            dnusbaum Devin Nusbaum added a comment -

            A PR was merged to update the documentation, but it has not been released yet.

            dnusbaum Devin Nusbaum added a comment - A PR was merged to update the documentation, but it has not been released yet.
            dnusbaum Devin Nusbaum made changes -
            Assignee Adrian Wyssmann [ papanito ]
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Fixed but Unreleased [ 10203 ]

            Hi, I've run into the same issue as being an Administrator allows me to approve my own processes. In my case this a problem, because I'm trying to implement a system where an additional administrator needs to approve the process, and the one that is requesting the process run is actually not in the list of the approvers acceptable. However, because of the issue mentioned above, this still allows the user to approve the process.

            atzimler Attila Tamas Zimler added a comment - Hi, I've run into the same issue as being an Administrator allows me to approve my own processes. In my case this a problem, because I'm trying to implement a system where an additional administrator needs to approve the process, and the one that is requesting the process run is actually not in the list of the approvers acceptable. However, because of the issue mentioned above, this still allows the user to approve the process.

            atzimler that could be an interesting scenario. Perhaps adding an option to allow/disallow admin in addition to the submitter list could do the trick. dnusbaum Do you think it's valuable to re-open this ticket or creating a new one? (or "refusing the scenario", also an option).

            wfollonier Wadeck Follonier added a comment - atzimler that could be an interesting scenario. Perhaps adding an option to allow/disallow admin in addition to the submitter list could do the trick. dnusbaum Do you think it's valuable to re-open this ticket or creating a new one? (or "refusing the scenario", also an option).
            dnusbaum Devin Nusbaum added a comment -

            To me, it still seems pointless, because an admin could always approve the input indirectly through tools like the script console with their elevated permissions, or create a new job that does what they want, and just run that. Anyone with admin permissions should be considered trusted, and if you do not trust them, then they should not be an admin. If you do trust them, then this just seems like something to be enforced socially by making sure the message for the input requests that a different admin approve the input.

            dnusbaum Devin Nusbaum added a comment - To me, it still seems pointless, because an admin could always approve the input indirectly through tools like the script console with their elevated permissions, or create a new job that does what they want, and just run that. Anyone with admin permissions should be considered trusted, and if you do not trust them, then they should not be an admin. If you do trust them, then this just seems like something to be enforced socially by making sure the message for the input requests that a different admin approve the input.

            Hi, I've worked around the issue with actually adding cycles into the groovy description of the pipeline. I just wanted to add a note on the fact that for my scenario is not a trust issue, it is more of avoiding potential accidents with production systems. Our admin team can freely adjust the build process too, but we are responsible and don't do that either for the purpose of circumventing protective measures.

            atzimler Attila Tamas Zimler added a comment - Hi, I've worked around the issue with actually adding cycles into the groovy description of the pipeline. I just wanted to add a note on the fact that for my scenario is not a trust issue, it is more of avoiding potential accidents with production systems. Our admin team can freely adjust the build process too, but we are responsible and don't do that either for the purpose of circumventing protective measures.
            dnusbaum Devin Nusbaum made changes -
            Link This issue is caused by JENKINS-48998 [ JENKINS-48998 ]

            People

              papanito papanito
              papanito papanito
              Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: