Containers: overriding HOME environment variable with mismatching /etc/passwd home causes issues

GitHub Actions runner currently seems to set container HOME environment variable to /github/home. Unfortunately, this is different from what the home directory is set to in the container’s /etc/passwd. For example, if the container is run as root, the home directory in /etc/passwd is usually /root.

This mismatch causes some unexpected issues like making caching more difficult. When caching Java M2 dependencies for example, the following does not work:

- uses: actions/cache@v2
   with:
     key: m2
     path: ~/.m2

This is because the Java user.home property is set to whatever is in /etc/passwd.

Would it be possible to have the runner not change HOME by default?

On a related note, it would be really nice if the GitHub runner’s parameters to docker containers were documented clearly somewhere.

[justfalter]

I’ve encountered this issue when two different workflows have executed on the same runner, but with containers running as different users. Files end up in the home directory that are owned by different users, resulting in permission denied errors. This can happen when a container is explicitly executed as a different user (ex: --user node:node), but the user can also be specified via Dockerfile’s USER command.

The following will run as root, and create a file in the home directory test-file. This file is owned by uid=0, gid=0.

jobs:
  runs-as-root:
    runs-on: [self-hosted, docker]
    container:
      image: node:latest
    steps:
      - run: |
          id
          touch ~/test-file

The following will do the same as above, but run as the node user with uid=1000, gid=1000. This fails with a Permission denied error because the ~/test-file already exists, but is owned by uid=0, gid=0.

jobs:
  runs-as-node:
    runs-on: [self-hosted, docker]
    container:
      image: node:latest
      options: --user node:node
    steps:
      - run: |
          id
          touch ~/test-file

We’ve come to the conclusion that the safest course of action is to try to run all containers as the root user, but this can be challenging when some software packages behave differently when running as root (ex: npm version 6 won’t execute lifecycle scripts when run as root), while others refuse to run at all (ex: postgresql’s pg_ctl refuses to run as root).

[nikola-jokic]

Hi everyone,

To help you with the workaround, I will provide more context to this issue and close it in favour of #863. We are aware of the permissions problem illustrated by issue #434.

The runner will mount docker volumes as you described above. Files you created inside this docker container will be owned by the corresponding user on your host machine, so if you created a file as a root user inside the mounted volume inside the container, it will be owned by the root outside of it. More generally, if you have a user with UID 1000 (let’s call it user user1) inside the container, and you have a user with UID 1000 outside of the container on your machine (let’s call that user runner), files created by the user1 inside the container will be owned by the user runner on your host machine. This will cause you issues if you create a user inside the container with UID that does not match any UID on your host machine.

That being said, we are aware of that problem and it is in our backlog. For updates on this issue please refer to the issues I have linked. Since we have this issue linked as well, it won’t be hard for us to find it when we start testing the fix.

I am sorry this issue is bothering you and I hope the explanation above helped a bit.