Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-19827

Docker Runner build will fail if the image used specifies a non-root user for the USER in the Dockerfile

      Summary

      Docker runner build will fail if the image used specifies a non-root user for the USER in the Dockerfile

      Environment

      Docker version 17.12.0-ce, build c97c6d6
      

      Steps to Reproduce

      1. Run a docker runner job using the image: instructure/core:latest

      Expected Results

      Build succeeds.

      Actual Results

      On versions pre-6.7.0 the below error is thrown in the build log:

      command	11-Apr-2018 14:31:49	Beginning to execute external process for build 'PROJ - PLAN - JOB #43 (PROJ-PLAN-JOB1-43)'\n ... running command line: \n/usr/bin/docker exec b54d80ca-e543-4e16-b0e2-613d8a8eb501 /tmp/intialiseContainer.sh\n ... in: /var/bamboo-home-new/xml-data/build-dir/92963244/PROJ-PLAN-JOB1\n
      error	11-Apr-2018 14:31:49	/bin/sh: 0: Can't open /tmp/intialiseContainer.sh
      error	11-Apr-2018 14:31:49	Failed to start docker container b54d80ca-e543-4e16-b0e2-613d8a8eb501
      error	11-Apr-2018 14:31:49	com.atlassian.bamboo.docker.DockerException: Error running Docker run command
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.docker.DockerContainerServiceImpl.run(DockerContainerServiceImpl.java:118)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.v2.build.agent.docker.DockerContainerControllerImpl.startContainerIfRequired(DockerContainerControllerImpl.java:78)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent.build(DefaultBuildAgent.java:173)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.v2.build.agent.BuildAgentControllerImpl.lambda$waitAndPerformBuild$0(BuildAgentControllerImpl.java:122)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.variable.CustomVariableContextImpl.withVariableSubstitutor(CustomVariableContextImpl.java:185)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.v2.build.agent.BuildAgentControllerImpl.waitAndPerformBuild(BuildAgentControllerImpl.java:117)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent$1.run(DefaultBuildAgent.java:126)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.utils.BambooRunnables$1.run(BambooRunnables.java:48)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.security.ImpersonationHelper.runWith(ImpersonationHelper.java:26)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.security.ImpersonationHelper.runWithSystemAuthority(ImpersonationHelper.java:17)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.security.ImpersonationHelper$1.run(ImpersonationHelper.java:41)
      error	11-Apr-2018 14:31:49		at java.lang.Thread.run(Thread.java:748)
      error	11-Apr-2018 14:31:49	Caused by: com.atlassian.utils.process.ProcessException: Error executing /usr/bin/docker exec b54d80ca-e543-4e16-b0e2-613d8a8eb501 /tmp/intialiseContainer.sh
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.docker.DockerContainerServiceImpl.execute(DockerContainerServiceImpl.java:252)
      error	11-Apr-2018 14:31:49		at com.atlassian.bamboo.docker.DockerContainerServiceImpl.run(DockerContainerServiceImpl.java:115)
      error	11-Apr-2018 14:31:49		... 11 more
      

      After 6.7.0, it will manifest generally as a permission issue on any of the script (.sh) files Bamboo attempts to execute within the container.

      Workaround

      • None, need to use an image that where docker exec commands are performed as root.

            [BAM-19827] Docker Runner build will fail if the image used specifies a non-root user for the USER in the Dockerfile

            Together with the problem stated [here|https://github.com/npm/rfcs/issues/546], it becomes a nightmare when trying to work around it.

            Kirill Deyko added a comment - Together with the problem stated [here| https://github.com/npm/rfcs/issues/546 ], it becomes a nightmare when trying to work around it.

            Please target to fix this in next release cycle. 

            Gaurav Gupta added a comment - Please target to fix this in next release cycle. 

            Yevhen added a comment - - edited

            I was able to reproduce it with 7.1.1. Is this really fixed pskierczynski?

            When executing script tasks in Docker, we actually use 2 scripts: runInDocker.sh in /tmp which calls the scriptBuildTask that has command line syntax. Since that script is mounted, not cp'ed and chmod, chowned by Bamboo, permission denied is expected:

            /tmp/runInDocker2036597224817806522.sh: 2: cd: can't cd to /home/eugene/Downloads/atlassian-bamboo-7.1.1/bamboo-home/xml-data/build-dir/TEST-TES4-JOB1
            /tmp/runInDocker2036597224817806522.sh: 4: /tmp/runInDocker2036597224817806522.sh: /home/eugene/Downloads/atlassian-bamboo-7.1.1/bamboo-home/temp/TEST-TES4-JOB1-44-ScriptBuildTask-1163266806075301163.sh: Permission denied

            This happens when a container is started as a non root user. It is reproduced with a script task only since this this task type we use 2 scripts.

            Yevhen added a comment - - edited I was able to reproduce it with 7.1.1. Is this really fixed pskierczynski ? When executing script tasks in Docker, we actually use 2 scripts: runInDocker.sh in /tmp which calls the scriptBuildTask that has command line syntax. Since that script is mounted, not cp'ed and chmod, chowned by Bamboo, permission denied is expected: /tmp/runInDocker2036597224817806522.sh: 2: cd: can't cd to /home/eugene/Downloads/atlassian-bamboo-7.1.1/bamboo-home/xml-data/build-dir/TEST-TES4-JOB1 /tmp/runInDocker2036597224817806522.sh: 4: /tmp/runInDocker2036597224817806522.sh: /home/eugene/Downloads/atlassian-bamboo-7.1.1/bamboo-home/temp/TEST-TES4-JOB1-44-ScriptBuildTask-1163266806075301163.sh: Permission denied This happens when a container is started as a non root user. It is reproduced with a script task only since this this task type we use 2 scripts.

            Hi Pawel, I was able to debug this further on my end after posting. It appears to be due to our container running as a user with non-root permissions. When the container runs as root, it works fine.

            Kyle Butler added a comment - Hi Pawel, I was able to debug this further on my end after posting. It appears to be due to our container running as a user with non-root permissions. When the container runs as root, it works fine.

            kbutler73 it may be the same symptom caused by different issue. Can you provide logs with error (here or with support case)? Or logs are actually the same as in this issue description?

            Pawel Skierczynski added a comment - kbutler73 it may be the same symptom caused by different issue. Can you provide logs with error (here or with support case)? Or logs are actually the same as in this issue description?

            Is this actually fixed in 6.7.0? I see it is marked as resolved, but I still see the issue after upgrading.

            Kyle Butler added a comment - Is this actually fixed in 6.7.0? I see it is marked as resolved, but I still see the issue after upgrading.

            grahamb, I'm sorry for broken expectations. Team is working hard to resolve found issues, release was postponed for some time. It's almost here. Stay tuned

            Alexey Chystoprudov added a comment - grahamb , I'm sorry for broken expectations. Team is working hard to resolve found issues, release was postponed for some time. It's almost here. Stay tuned

            It's now the second week of October. When will 6.7 be released?

            Graham Ballantyne added a comment - It's now the second week of October. When will 6.7 be released?

            grahamb, it's now planned for a first week of October

            Alexey Chystoprudov added a comment - grahamb , it's now planned for a first week of October

            @Alexey Chystoprudov: any update on a release date for 6.7?

             

             

            Graham Ballantyne added a comment - @Alexey Chystoprudov: any update on a release date for 6.7?    

            Yes. It's fixed in Bamboo 6.7 planned for release in a month

            Alexey Chystoprudov added a comment - Yes. It's fixed in Bamboo 6.7 planned for release in a month

            Any update ?

            Exploitation BRS added a comment - Any update ?

            Hi Atlassian, any update on this issue?

            Graham Ballantyne added a comment - Hi Atlassian, any update on this issue?

            This is a serious shortcoming... there are security issues that are exacerbated by forcing the images to use the root user, and allowing end users to mount whatever they like from the host system.

            Jamie Echlin _ScriptRunner - The Adaptavist Group_ added a comment - This is a serious shortcoming... there are security issues that are exacerbated by forcing the images to use the root user, and allowing end users to mount whatever they like from the host system.

            We are running into the same issue running a Gradle build using the `gradle:latest` Docker image.

            This image has `USER gradle` set

            Deleted Account (Inactive) added a comment - We are running into the same issue running a Gradle build using the `gradle:latest` Docker image. This image has `USER gradle` set

            I'm the reporter of the bug. Not being able to use a container that specifies a non-root user has a number of issues. One that I'm running into is that any files generated in the container will be owned as root in the host. We have Bamboo running as a non-root user, which means that build options like clean source checkouts and cleaning the working directory after each build don't work; Bamboo can't delete the root-owned files.

            Would a quick fix not be to use the `-u root` flag to `docker exec` when running /tmp/intialiseContainer.sh ?

            Graham Ballantyne added a comment - I'm the reporter of the bug. Not being able to use a container that specifies a non-root user has a number of issues. One that I'm running into is that any files generated in the container will be owned as root in the host. We have Bamboo running as a non-root user, which means that build options like clean source checkouts and cleaning the working directory after each build don't work; Bamboo can't delete the root-owned files. Would a quick fix not be to use the `-u root` flag to `docker exec` when running /tmp/intialiseContainer.sh ?

            Clint added a comment -

            I've just run into this too.. I get the same error, but from the command line I can see that my container has actually started (and is working as expected).

            Clint added a comment - I've just run into this too.. I get the same error, but from the command line I can see that my container has actually started (and is working as expected).

              pskierczynski Pawel Skierczynski
              jowen@atlassian.com Jeremy Owen
              Affected customers:
              15 This affects my team
              Watchers:
              30 Start watching this issue

                Created:
                Updated: