Run the job.container as the same user of the host VM by default

[felipecrs]

Description

Run the containers as the same user running on the host (the VM) by default, or at least provide an option. The related docker option would be docker run --user "$(id -u):$(id -g)".

Containers job.container runs as the container's default user by default, which often is root. This causes some weird behaviors because the workspace on the GitHub runner is mounted to the container, and no other user (other than the Runner user) has permission to write on it. This is what makes @actions/checkout fail when running on containers.

As Jenkins does, this should be made by default. Users who might want to run as a different user can still use the --user docker option.

Workaround

As suggested by @xanantis:

jobs:
  configure:
    runs-on: ubuntu-latest
    outputs:
      uid_gid: ${{ steps.get-user.outputs.uid_gid }}
    steps:
      - id: get-user
        run: echo "::set-output name=uid_gid::$(id -u):$(id -g)"

  clone-and-install:
    needs: configure
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/vscode/devcontainers/base:ubuntu
      options: --user ${{ needs.configure.outputs.uid_gid }}
    steps:
      - uses: actions/checkout@v2

It's even funny to have to do such a thing.

[BlueskyFR]

Can reproduce, I know it's been 2 years now but is there any update?

[sulfasTor]

Description

Run the containers as the same user running on the host (the VM) by default, or at least provide an option. The related docker option would be docker run --user "$(id -u):$(id -g)".

Containers job.container runs as the container's default user by default, which often is root. This causes some weird behaviors because the workspace on the GitHub runner is mounted to the container, and no other user (other than the Runner user) has permission to write on it. This is what makes @actions/checkout fail when running on containers.

As Jenkins does, this should be made by default. Users who might want to run as a different user can still use the --user docker option.

Workaround

As suggested by @xanantis:

jobs:
  configure:
    runs-on: ubuntu-latest
    outputs:
      uid_gid: ${{ steps.get-user.outputs.uid_gid }}
    steps:
      - id: get-user
        run: echo "::set-output name=uid_gid::$(id -u):$(id -g)"

  clone-and-install:
    needs: configure
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/vscode/devcontainers/base:ubuntu
      options: --user ${{ needs.configure.outputs.uid_gid }}
    steps:
      - uses: actions/checkout@v2

It's even funny to have to do such a thing.

This won't work if you have a pool of self-hosted runners and jobs are dispatched by different runners. ID's may mismatch.

[felipecrs]

That's true.

[russellsch]

Does anyone have any suggestions for dealing with this on self-hosted runners?

[xanantis]

@russellsch There are two options for you: Rootless Docker Podman, with podman.socket enabled. You may have to create a symlink for /usr/bin/docker to /usr/bin/podman.

Before rootless docker was available and podman supported interaction over a socket, I used parameter injection to inject --user for create, exec, and run commands.

[jcelerier]

any hope of seeing this little change one day ? there's no correct solution to this right now