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

CommandDuringBuild not automatically authenticated

    Details

    • Similar Issues:

      Description

      Some CommandDuringBuild implementations, such as SetBuildResultCommand, check permissions. This is necessary to prevent a random user (with at least Item.READ permission) from running one of these commands on someone else's build from an external command shell. (Cf. JENKINS-24080.)

      Yet Jenkins provides no assistance in authenticating such commands. So if you are running in a properly secured instance and want to run set-build-result, your job would have to provide an SSH private key or password for a user with permissions on the job. Managing such credentials safely could be tricky.

      It would be better if this were automatic, when the CLI command is indeed run from inside the build (say in a shell step). Perhaps $JENKINS_SERVER_COOKIE could be inspected on the CLI side and compared to Run.getCharacteristicEnvVars? Assuming there is a match, you could either

      • Set the transport authentication for the command to the authentication in effect in Run.getExecutor, if not just SYSTEM. (Executor would need to have a method reporting its current authentication. Running workUnit.context.item.authenticate() again and assuming that the result is the same is unsafe since a job configuration might have changed since it started running.)
      • Return null from getCurrentlyBuilding in case there is not a match, and removing permission checks from command implementations. This is arguably better because it will make the job work correctly even if the authentication in effect during the build is for a user (for example anonymous) who would not otherwise generally have those permissions on the job; or when there is no authentication in effect during the build at all.

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-16956 [ JENKINS-16956 ]
            jglick Jesse Glick made changes -
            Description Some {{CommandDuringBuild}} implementations, such as {{SetBuildResultCommand}}, check permissions. (Oddly, {{Item.BUILD}} in this case; I would have expected {{Run.UPDATE}}. And {{SetBuildParameterCommand}} does no check at all.) This is necessary to prevent a random user (with at least {{Item.READ}} permission) from running one of these commands on someone else's build from an external command shell. ({{getCurrentlyBuilding}} does not even check {{Run.isBuilding}}, so this could even be used to mangle a _completed_ build's state, such as parameters via {{SetBuildParameterCommand}}. {{SetBuildResultCommand}} would not work on a finished build because of checks inside {{Run.setResult}}.)

            Yet Jenkins provides no assistance in authenticating such commands. So if you are running in a properly secured instance and want to run {{set-build-result}}, your job would have to provide an SSH private key or password for a user with permissions on the job. Managing such credentials safely could be tricky.

            It would be better if this were automatic, when the CLI command is indeed run from inside the build (say in a shell step). Perhaps {{$JENKINS_SERVER_COOKIE}} could be inspected on the CLI side and compared to {{Run.getCharacteristicEnvVars}}? Assuming there is a match, you could either

            * Set the transport authentication for the command to the authentication in effect in {{Run.getExecutor}}, if not just {{SYSTEM}}. ({{Executor}} would need to have a method reporting its current authentication. Running {{workUnit.context.item.authenticate()}} again and assuming that the result is the same is unsafe since a job configuration might have changed since it started running.)
            * Return null from {{getCurrentlyBuilding}} in case there is _not_ a match, and removing permission checks from command implementations. This is arguably better because it will make the job work correctly even if the authentication in effect during the build is for a user (for example {{anonymous}}) who would not otherwise generally have those permissions on the job; or when there is no authentication in effect during the build at all.
            Some {{CommandDuringBuild}} implementations, such as {{SetBuildResultCommand}}, check permissions. This is necessary to prevent a random user (with at least {{Item.READ}} permission) from running one of these commands on someone else's build from an external command shell. (Cf. JENKINS-24080.)

            Yet Jenkins provides no assistance in authenticating such commands. So if you are running in a properly secured instance and want to run {{set-build-result}}, your job would have to provide an SSH private key or password for a user with permissions on the job. Managing such credentials safely could be tricky.

            It would be better if this were automatic, when the CLI command is indeed run from inside the build (say in a shell step). Perhaps {{$JENKINS_SERVER_COOKIE}} could be inspected on the CLI side and compared to {{Run.getCharacteristicEnvVars}}? Assuming there is a match, you could either

            * Set the transport authentication for the command to the authentication in effect in {{Run.getExecutor}}, if not just {{SYSTEM}}. ({{Executor}} would need to have a method reporting its current authentication. Running {{workUnit.context.item.authenticate()}} again and assuming that the result is the same is unsafe since a job configuration might have changed since it started running.)
            * Return null from {{getCurrentlyBuilding}} in case there is _not_ a match, and removing permission checks from command implementations. This is arguably better because it will make the job work correctly even if the authentication in effect during the build is for a user (for example {{anonymous}}) who would not otherwise generally have those permissions on the job; or when there is no authentication in effect during the build at all.
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-24080 [ JENKINS-24080 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 154573 ] JNJira + In-Review [ 178844 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-41745 [ JENKINS-41745 ]
            jglick Jesse Glick made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Won't Do [ 10001 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick Jesse Glick
              • Votes:
                1 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: