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

Auto-chown option to fix files in workspaces created as root

      Docker operations can create files within the workspace that are owned by the root user – it is impossible to clear or remove these files by normal methods (the Jenkins user isn't permissioned).  This commonly happens when someone uses the root user to run a Docker operation with a local directory mapped in as a volume to return artifacts. 

      I've noted no less than 4 users having major issues as a result of this problem in the last week (see stack trace at bottom) – but it can result in hanging builds and consuming excessive on-master resources. 

      Now, there are a couple ways to add features that can prevent this problem: 

      1) Add an "permissionsFix" argument to docker.inside and some other docker commands that goes back and tries to do the needful to fix permissions (probably by launching a docker container that creates a user mapping to Jenkins dynamically and doing a chown). 

      2) Add a 'chown' operation to the docker options that launches a special container as above. 

      3) Try some custom hack with Docker itself so the container sees a root user internally but it still maps back out to Jenkins (maybe possible?)

       

          [JENKINS-46686] Auto-chown option to fix files in workspaces created as root

          Jesse Glick added a comment -

          Hard to evaluate without a concrete example of a script reproducing the issue.

          While it is possible to docker exec a task to chown -R 1000.1000 $workspace before proceeding, effectively a poor man’s sudo, this seems pretty risky. A safer starting point would be some detector that looks for root-owned files after operations which might have led to that outcome, and immediately fail the build with a descriptive error, so the developer can go back in and fix the sources.

          Jesse Glick added a comment - Hard to evaluate without a concrete example of a script reproducing the issue. While it is possible to docker exec a task to chown -R 1000.1000 $workspace before proceeding, effectively a poor man’s sudo , this seems pretty risky. A safer starting point would be some detector that looks for root -owned files after operations which might have led to that outcome, and immediately fail the build with a descriptive error, so the developer can go back in and fix the sources.

          Sam Van Oort added a comment -

          jglick Unfortunately content in root-owned folders might not even be visible to the Jenkins user (depending on the setting).  

          The easiest way to accomplish this is something like:

          docker run -it --rm -v $(pwd):/test -w /test alpine:3.6 sh -c 'whoami > userFile'

          Note that this not create a file permissioned as root in Docker For Mac due to an auto-chown operation it does (nudge-nudge). 

          I'm working up a proof-of-concept implementation of this right now, at least as a helper for people trapped by this issue. 

          Sam Van Oort added a comment - jglick Unfortunately content in root-owned folders  might not even be visible to the Jenkins user (depending on the setting).   The easiest way to accomplish this is something like: docker run -it --rm -v $(pwd):/test -w /test alpine:3.6 sh -c 'whoami > userFile' Note that this not create a file permissioned as root in Docker For Mac due to an auto-chown operation it does (nudge-nudge).  I'm working up a proof-of-concept implementation of this right now, at least as a helper for people trapped by this issue. 

          Sam Van Oort added a comment -

          Auto-chown is less trivial than I'd hoped after tinkering, since it's container-dependent and you don't necessarily want to chown all the things in the workspace (potentially expensive operation) – potentially requires a user created in-container which is different depending on platform. 

          Option B would be to use a stock container that can do the user setup and chown, but that runs as a new container run.  Bit hacky but would work.

          I think this is a pretty valuable feature, just not sure how to actually implement it best. 

          Sam Van Oort added a comment - Auto-chown is less trivial than I'd hoped after tinkering, since it's container-dependent and you don't necessarily want to chown all the things in the workspace (potentially expensive operation) – potentially requires a user created in-container which is different depending on platform.  Option B would be to use a stock container that can do the user setup and chown, but that runs as a new container run.  Bit hacky but would work. I think this is a pretty valuable feature, just not sure how to actually implement it best. 

          Issue JENKINS-24440 seems to be related.

          Yuri Govorushchenko added a comment - Issue JENKINS-24440 seems to be related.

            Unassigned Unassigned
            svanoort Sam Van Oort
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: