FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR and security scanner don't play well
Summary
FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR is to solve security issue of building containers with -rw-rw-rw
permissions. Ironically it breaks other security tool called security scanner:
fatal: unsafe repository ('/builds/rPrca3qv/0/group/project' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /builds/rPrca3qv/0/group/project
The container with registry.gitlab.com/security-products/secrets:3
image runs as root
, so the chown
procedure is omitted and the files remain to ownership of the last job:
root@runner7 /srv/gitlab-runner# ls -ldn /builds/rPrca3qv/0/group/project
drwxr-xr-x 8 1000 1000 4096 Jul 18 15:18 /builds/rPrca3qv/0/group/project
Git in registry.gitlab.com/security-products/secrets:3
image is 2.34.2
I've tested also:
- 2.20.1: does not check for unsafe repository
- 2.34.4: also checks for unsafe repository
Steps to reproduce
- add your own runner. gitlab.com runners do not preserve
/builds
state across jobs - enable
FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR
(project .gitlab-ci.yml or config.toml of the runner) - add
secret_detection
job to pipeline - run a job that uses non-root user using the named gitlab runner
- run the
secret_detection
job to use the same gitlab runner
Example Project
What is the current bug behavior?
Fatal error, job is aborted
What is the expected correct behavior?
Job to run
Possible fixes
- always run chown when feature flag is enabled, even if current user is
root
(change in runner codebase): gitlab-runner!3533 (closed) - skip the security check:
git config --global --add safe.directory
. mitigation: #368133 (comment 1032528491) - run chown in
secret_detection
job itself (solves only particular job problem) - run
secret_detection
container as non-root (solves only particular job problem)
Edited by Elan Ruusamäe