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

  1. add your own runner. gitlab.com runners do not preserve /builds state across jobs
  2. enable FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR (project .gitlab-ci.yml or config.toml of the runner)
  3. add secret_detection job to pipeline
  4. run a job that uses non-root user using the named gitlab runner
  5. 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

  1. always run chown when feature flag is enabled, even if current user is root (change in runner codebase): gitlab-runner!3533 (closed)
  2. skip the security check: git config --global --add safe.directory. mitigation: #368133 (comment 1032528491)
  3. run chown in secret_detection job itself (solves only particular job problem)
  4. run secret_detection container as non-root (solves only particular job problem)
Edited by Elan Ruusamäe