EACCESS when running in a rootless self-hosted runner

[jwoodrow]

Hi 👋

First off a bit of context. We've configured our self-hosted server to make it as secure as possible and so we have docker configured in rootless mode. This was causing us issues with the checkout stage before when we did this:

      - name: Checkout code
        uses: actions/checkout@v3

The error we would get would be along the lines of this:

EACCES: permission denied, open '/__w/_temp/some/hashed/path'

but it was fixed by changing it to this:

      - name: chown workspace
        run: |
          sudo chown -R $(whoami):$(whoami) $GITHUB_WORKSPACE

      - name: Checkout code
        uses: actions/checkout@v3
        with:
          set-safe-directory: false

Now that our unit tests are working again on the self-hosted runner (and checkout is too) I started converting our cypress workflow to make it run on self-hosted but we're now encountering a similar issue once again.

      - name: Cypress (Chrome)
        uses: cypress-io/github-action@v4
        with:
          start: bundle exec rails s
          wait-on: 'http://localhost:5002/health_check'
          wait-on-timeout: 60
          browser: chrome

and the error we're getting is this:

EACCES: permission denied, open '/__w/_temp/_runner_file_commands/set_env_06dd188a-6b79-4322-b277-726a592d78d2'

My question was two-fold:

1. Is there a similar option to the set-safe-directory: false that the checkout action has in place which seems to avoid using temp files and directory during the checkout phase ?
2. If there isn't, would I be better off configuring cypress and all, myself during my tests and not use any actions ?

I have control over the UID/GID of the docker container user, since we're using our own base image but from my experience trying to debug a similar error with the checkout phase setting it to 1001/1001 didn't actually solve anything last time and only brought more problems because I had to change permissions everywhere on the self-hosted runner to work (which ended up in me simply ripping it down and starting from scratch...)

Thanks for any insight and feel free to ask me to test some things out !

[jwoodrow]

So what was happening is that since running in rootless my docker daemon in rootless mode I had the following mapping

• root => host_user
• container_user => nobody (remapped to a UID = host_user subuid)

In my solution for the checkout action (with set-safe-directory: false) I needed to chown the workspace because the second part of the action command is run as the current user (I think) but this would cause potential issues down the line since the new mapping would trickle down to the host system, rendering the files uneditable without a sudo which kind of defeats the point of running docker as a non-sudo user...

So I've kind of switched things around. I'm now using ACL to control local access for the docker user and not touching the owner of anything in the repository, although I still need to chmod 777 for the duration of the checkout step which kind of bothers me.

Now that I've done this the _temp folder is no longer owned by the wrong user but I'm getting a new kind of error from cypress.

/usr/bin/docker exec  32c660162f5d95ac36389302b4ff883a04231ffe95d80e6739b27df3d15577c3 sh -c "cat /etc/*release | grep ^ID"
Error: Unable to locate executable file: yarn. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

any idea what's going on here ?

I'm also open to ideas on what I could do to avoid having to chmod 777 my workspace (this is needed because the checkout step does a clean but if I don't switch other access rights it can't delete current content)

[MikeMcC399]

@jwoodrow

Were you able to resolve your issue?

It seems a bit out of scope as far as github-action is concerned.

[jwoodrow]

@jwoodrow

Were you able to resolve your issue?

It seems a bit out of scope as far as github-action is concerned.

IIRC we stopped using the github action and opted for full manual setup of cypress instead

[MikeMcC399]

@jwoodrow

IIRC we stopped using the github action and opted for full manual setup of cypress instead

I can understand if you did that. github-action is more of a convenience wrapper to pass parameters to Cypress and if you use it in a conventional way it works fine. Once you start to have special needs it can however get in the way.

Many thanks for responding! I'll close the issue off now.