fatal: unsafe repository (REPO is owned by someone else) in other workflow steps after running checkout

Description

Git recently pushed a change in response to a cve that causes git commands to fail if the parent directory changes ownership from the current directory. You may see errors like

  /usr/bin/git remote add origin https://github.com/wez/wezterm
  Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)

on self hosted runners, or if your job uses a container.

Workaround: Checkout is failing

This was fixed in the checkout action #760

Please update to the latest version of checkout. v3, v3.0.1, v2 and v2.4.1 all contain the fix for this issue. If you are still seeing the checkout action fail on these versions, please file an issue.

Workaround: Other steps are failing

Since we don’t persist that configuration, you may still see this error if your job uses git commands outside of the checkout action. If so, you just need to set the configuration value yourself.

Simply set the GITHUB_WORKSPACE as a safe directory.

git config --global --add safe.directory "$GITHUB_WORKSPACE"

If your github workspace starts off with //, you may need to set it via

git config --global --add safe.directory "%(prefix)/$GITHUB_WORKSPACE"

If you are failing inside a container action, you will need to run this inside your container action script.

Why is the parent directory owned by a different user?

When the runner maps the working directory mounts into your job container or step container they are owned by the runner user, not the container user, causing this issue. While any folders created may be owned by the container user.

Why don’t we persist the configuration we use in actions/checkout

We could try to persist this temporary global configuration we set in checkout for the duration of your job, but there are few problems with that:

1. If you run checkout on the root machine, and you have a container action with git commands, you are still going to fail unless you set the config in that container, which checkout can’t do for another step
2. Overwriting the git global config and not persisting any changes back to the original global config may break some user expectations on self hosted runners.
3. It only really addresses this issue for checkout users, but this is more of an actions ecosystem problem

Whats next

This is better solved at an actions ecosystem level, rather than solving it in the checkout action. That way, users not using checkout and users using container actions can take advantage of that solution. This is something our team is actively looking into now.

[JasonGross]

Simply set the GITHUB_WORKSPACE as a safe directory.

git config --global --add safe.directory "$GITHUB_WORKSPACE"

It seems like this is insufficient if there are submodules? (log)

[Skarlso]

This popped up on our radar at https://github.com/weaveworks/eksctl after upgrading to v3 AND we updated one of our build containers. With an old container ( and it looks like an older git version ) this IS working. But with a new container this is now breaking and we have to re-apply the safe folder before our flow begins. Checkout applies the safe folder to /__w/eksctl/eksctl but the action coming after it, doesn’t work anymore. ( fails with not a git directory error ).

Run ./.github/actions/setup-identity
Run git config user.name "weaveworksbot"
fatal: not in a git directory
Error: Process completed with exit code 12

Doing

      - name: Trust GitHub workspace
        run:
          git config --global --add safe.directory '/__w/eksctl/eksctl'

Before the setup-identity works, but I don’t understand why it’s suddenly needed when the only thing we updated was the container. 😃