Gitlab docker-runner does not mount uppercase symlinks to devices correctly
<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label. For the Community Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug For the Enterprise Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Gitlab docker runner does not mount uppercase symlinks to devices correctly ### Steps to reproduce 0. Prequisites: - Gitlab-runner on Linux (here: Ubuntu Disco) - Docker - Gitlab-runner with Docker socket mounted into it, so it can build silbling containers 1. Udev rule: Create udev rule for existing device (example: `/dev/ttyUSB0` of a serial interface). That creates a `SYMLINK` to 'ttyUSB_Customname` 2. Mount the device (`/dev/ttyUSB0`) as well as the symlink (`/dev/ttyUSB_customname`) with settings in the Gitlabs `config.toml` 3. Build a project that uses an image and build stepts that somehow use the device (example: `file /dev/ttyUSB0`, `file /dev/ttyUSB_Customname`) The result: `/dev/ttyUSB0` will show up and is working, `/dev/ttyUSB_Customname` is not existant in the container at all. (How one can reproduce the issue - this is very important) ### Example Project ### What is the current *bug* behavior? ... but wait, there is more: If we turn up the gitlab-ci build level to `debug` we see a log output that tells us that `/dev/ttyusb_customname` is being mounted onto `/dev/ttyusb_customname` - wait a minute, why the lowercase? If I create a lowercase symlink rule, instead of the case sensitive one - it actually works! ### What is the expected *correct* behavior? Being able to mount symlinks to devices that include uppercase (What you should see instead) ### Relevant logs and/or screenshots ### Output of checks #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes (If you can, link to the line of code that might be responsible for the problem)
issue