-
New Feature
-
Resolution: Unresolved
-
Major
-
None
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?)
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.