More than 1024 characters in stderr output of used image leads to runner system failure if FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR feature is enabled

Summary

We use in our CI:

  1. a runner (v15.8.0) with FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR enabled
  2. an image in jobs using a non-root user
  3. its entrypoint logs on stderr some information about its processing

We have runner system failure in some cases and found that it only happened if entrypoint outputs more than 1024 bytes of data on stderr.

Steps to reproduce

I do provide detailed information on how to reproduce issue and runner's code analysis results from my investigations in a public project https://gitlab.com/cboitel/runner-system-failure.

Actual behavior

Runner reports a system failure if image outputs more than 1024 characters on stderr.

Expected behavior

No errors reported and job completes as expected

Relevant logs and/or screenshots

See repository in which i provided screenshots and code analysis in which i found limitwriter helper to be the root cause.

Environment description

My provided project uses Gitlab.com shared runners with which i could reproduce runner system failures.

Used GitLab Runner version

My provided project uses Gitlab.com shared runners :

  • i experienced it on v15.8.0
  • gitlab.com uses a 15.9.x base
  • from code analysis, uses is still relevant for latest runner release v15.10.1

Possible fixes

See code analysis in project repository which includes lines of codes involved:

  1. limitwriter helper could be updated so that it silently limits the buffer size
  2. limitwriter helper could be updated so that one can ask to silently exceeded capacity errors when needed
  3. an internal limitwriter dedicated to docker be created since it may