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

[thboop]

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.

[me-and]

@thboop I agree with everything you've written here, and thank you for getting the fix for this action sorted so quickly! I think I'm a little confused about why this ticket is here, though; should this be raised and tracked over at actions/runner?

[thboop]

@thboop I agree with everything you've written here, and thank you for getting the fix for this action sorted so quickly! I think I'm a little confused about why this ticket is here, though; should this be raised and tracked over at actions/runner?

🏅 Its a good point that this is more appropriate for the runner repository, however given the nature of this breaking workflows, and the overall concern and questions folks had about what is happening and why, I though I would put it closer to where we are seeing the most users comment about this issue. I may move it in the near future over to the runner repo.