As described in https://gitlab.com/gitlab-org/gitlab/-/issues/418292, running the FIPS image with a shell executor fails out of the box for two reasons: 1. In the [prep job](https://staging.gitlab.com/gitlab-qa-sandbox-group-5/qa-test-2023-07-13-15-20-25-fab53b9c2f147b8f/pipeline-with-manual-job-75e19ffb41c1400d/-/jobs/46524226) it's throwing `mkdir: cannot create directory '/builds': Permission denied` 2. In the [build jobs](https://staging.gitlab.com/gitlab-qa-sandbox-group-5/qa-test-2023-07-13-15-20-25-fab53b9c2f147b8f/pipeline-with-manual-job-75e19ffb41c1400d/-/jobs/46524227) it's throwing `Password: su: Authentication failure`. This happens because due to https://gitlab.com/gitlab-org/gitlab-runner/-/commit/51d5167c9b5584d8a4edfca916041073d50b6353: 1. The image runs as UID 1001 by default (a non-existent user). This user doesn't have the ability to `mkdir /builds`. 2. `--user=gitlab-runner` is passed to the runner. This causes the shell executor to run `su`: https://gitlab.com/gitlab-org/gitlab-runner/-/blob/f29584e83f2b39572d44cc15efbced87a928d1b4/shells/bash.go#L361-375. However, normally `su` can only be run by `root`, so the we get the `Password: su: Authentication failure` error. @ratchade Was UID 1001 supposed to be `gitlab-runner`? UPDATE: Yes, for OpenShift (https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1069#note_282334875), and therefore we need `--user=root` in the arguments. On the FIPS image, it appears UID 998 belongs to `gitlab-runner`. Perhaps we should consider making USER a configurable value and the entrypoint conditional on whether it is already `gitlab-runner`.