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

Question

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

thboop opened this issue 2 years ago · 9 comments

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:

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
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.
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.

Answer 1 · 2022-04-14T19:54:54.000Z

@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?

Answer 2 · 2022-04-14T20:05:47.000Z

@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.

Answer 3 · 2022-04-15T13:18:54.000Z

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)

Answer 4 · 2022-04-20T22:23:26.000Z

v3, v3.0.1, v2 and v2.4.1 all contain the fix for this issue.

Is v1 affected by this and, if so, will it be possible for a fix be provided for actions/checkout@v1?

I am a publisher of a docker-based Action that depends on actions/checkout as a prerequisite step. Many of our users have been using this action since 2019 and, as a result, are often using the v1 version of this action. If a fix would be provided for v1 it may obviate the need for our users to update the action.

I also understand there may be a fix at the Actions ecosystem level. I'm hopeful this would provide the same effect in absence of a fix for v1.

In the meantime, we are working on providing guidance to our potentially affected users to deal with this by upgrading to actions/checkout@v3, although we are concerned that the version hop from v1 may introduce unexpected issues for our users.

In any case, it would be good to know if v1 is affected and if the team is looking at the possibility of porting a fix for v1. Thanks!

Answer 5 · 2022-05-16T12:25:23.000Z

I have a similar issue running workflow in the container. Probably, that happens because $GITHUB_WORKSPACE and github.workspace resolves to different paths (#785). Seems like actions/checkout adds only github.workspace path to the git safe directory configuration.
Probably it makes sense to add $GITHUB_WORKSPACE path in action/checkout implementation too.

Answer 6 · 2022-06-16T13:51:35.000Z

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. :)

Answer 7 · 2023-07-12T04:47:55.000Z

If you use a Docker container, downgrading to actions/checkout@v1 also fixes the issue. Not sure why isn't mentioned...

Answer 8 · 2023-11-30T11:35:34.000Z

I fixed it with :

git config --global --add safe.directory "*"

but i dont know if it is the correct way

Answer 9 · 2024-01-22T07:21:28.000Z

Even the action marks path as a safe directory, it overrides HOME env before. This was made intentionally (link). I don't know the exact reason though. When you run next step within workflow, HOME env is reset, and the dir becomes unsafe.
Here is a minimal example showing that changing HOME env makes the difference:

Example Workflow

name: Example of Missing Safe Dir

on:
  pull_request:
    branches: [ master ]
  push:
    branches: [ master ]

jobs:
  test-git-config:
    runs-on: ubuntu-22.04
    container: ubuntu:jammy-20240111

    steps:
      - name: Install Git CLI
        run: |
          apt-get update
          apt-get install git -y

      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Test Git Configuration and Environment
        run: |
          # Test as is, fail
          echo "Testing git status command:"
          git status && echo success || echo fail

          # Save HOME value
          ORIGINAL_HOME=$HOME
          echo "Original HOME: $ORIGINAL_HOME"

          # Override HOME value, mark directory as safe
          export HOME=/tmp/newhome
          mkdir -p $HOME
          git config --global --add safe.directory /__w/checkout-action-issue/checkout-action-issue
          echo "Git config added in overridden HOME"

          # Test with overridden HOME, success
          echo "Testing git status command:"
          git status && echo success || echo fail

          # Reset HOME to original value
          export HOME=$ORIGINAL_HOME
          echo "HOME reset to original: $HOME"

          # Test again after resetting HOME
          echo "Testing git status command:"
          git status && echo success || echo fail

          # Mark directory as safe with original HOME
          git config --global --add safe.directory /__w/checkout-action-issue/checkout-action-issue

          # Test after marking directory as safe with original HOME, success
          echo "Testing git status command:"
          git status && echo success || echo fail

Output

Testing git status command:
fatal: detected dubious ownership in repository at '/__w/checkout-action-issue/checkout-action-issue'
To add an exception for this directory, call:

	git config --global --add safe.directory /__w/checkout-action-issue/checkout-action-issue
fail
Original HOME: /github/home
Git config added in overridden HOME
Testing git status command:
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
success
HOME reset to original: /github/home
Testing git status command:
fatal: detected dubious ownership in repository at '/__w/checkout-action-issue/checkout-action-issue'
To add an exception for this directory, call:

	git config --global --add safe.directory /__w/checkout-action-issue/checkout-action-issue
fail
Testing git status command:
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
success