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

            Hide
            jglick Jesse Glick added a comment -

            Indeed.

            Show
            jglick Jesse Glick added a comment - Indeed.
            Hide
            danielbeck Daniel Beck added a comment -

            Jesse Glick Should we just Won't Fix this? IIRC all of these require a channel?

            Show
            danielbeck Daniel Beck added a comment - Jesse Glick Should we just Won't Fix this? IIRC all of these require a channel?
            Hide
            jglick Jesse Glick added a comment -

            Seems like the wrong place for an extension point—users cannot be expected to know better what a secure and appropriate choice would be.

            Show
            jglick Jesse Glick added a comment - Seems like the wrong place for an extension point—users cannot be expected to know better what a secure and appropriate choice would be.
            Hide
            danielbeck Daniel Beck added a comment -

            Make it an extension point and allow users to choose their favorite compromise of security vs. convenience, with the default a neutral "don't authenticate", a bit like the current markup formatter config?

            Show
            danielbeck Daniel Beck added a comment - Make it an extension point and allow users to choose their favorite compromise of security vs. convenience, with the default a neutral "don't authenticate", a bit like the current markup formatter config?
            Hide
            jglick Jesse Glick added a comment -

            Right, there is a chance of an environment variable leaking to others in the build log or similar. An alternative would be a designated file in the slave root containing a secret which the CLI agent would have to be modified to look for and send back to the master; this would not be protected from other builds on the same slave, but then again neither is your workspace. The ideal is to send the secret over a file descriptor inherited only via things started by the Launcher (akin to how ssh-agent works), but this is not portable to Windows that I know of.

            Show
            jglick Jesse Glick added a comment - Right, there is a chance of an environment variable leaking to others in the build log or similar. An alternative would be a designated file in the slave root containing a secret which the CLI agent would have to be modified to look for and send back to the master; this would not be protected from other builds on the same slave, but then again neither is your workspace. The ideal is to send the secret over a file descriptor inherited only via things started by the Launcher (akin to how ssh-agent works), but this is not portable to Windows that I know of.
            Hide
            danielbeck Daniel Beck added a comment -

            Environment variables may be too public to act as authorization.

            Show
            danielbeck Daniel Beck added a comment - Environment variables may be too public to act as authorization.
            Hide
            jglick Jesse Glick added a comment -

            Another option would be to define a BuildWrapper which sets an environment variable during the build to a random UUID which CommandDuringBuild, and perhaps any CLICommand, would check for; if set, the transport authentication would be set automatically to that of the build, and a flag set so that commands could decide to skip permission checks for the running build.

            Such a build wrapper could also ensure that jenkins-cli.jar is available on the slave machine in $JENKINS_CLI_JAR, so that you would not be required to download it manually, which would make running CLI commands from inside a build a lot more convenient. Of course this could be done automatically on any slave without requiring a custom build wrapper, but that would affect performance of everybody.

            (Defining a Builder is also an option, though this gives less flexibility for people who want to embed CLI commands in the middle of shell scripts and the like.)

            Show
            jglick Jesse Glick added a comment - Another option would be to define a BuildWrapper which sets an environment variable during the build to a random UUID which CommandDuringBuild , and perhaps any CLICommand , would check for; if set, the transport authentication would be set automatically to that of the build, and a flag set so that commands could decide to skip permission checks for the running build. Such a build wrapper could also ensure that jenkins-cli.jar is available on the slave machine in $JENKINS_CLI_JAR , so that you would not be required to download it manually, which would make running CLI commands from inside a build a lot more convenient. Of course this could be done automatically on any slave without requiring a custom build wrapper, but that would affect performance of everybody. (Defining a Builder is also an option, though this gives less flexibility for people who want to embed CLI commands in the middle of shell scripts and the like.)
            Hide
            jglick Jesse Glick added a comment -

            Oddly, SetBuildDisplayNameCommand is not a CommandDuringBuild. You would expect this to be a natural thing to do from inside a build.

            Show
            jglick Jesse Glick added a comment - Oddly, SetBuildDisplayNameCommand is not a CommandDuringBuild . You would expect this to be a natural thing to do from inside a build.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: