Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checkout is owned by a different user inside the container #47

Closed
junghans opened this issue Sep 27, 2019 · 6 comments
Closed

checkout is owned by a different user inside the container #47

junghans opened this issue Sep 27, 2019 · 6 comments

Comments

@junghans
Copy link

If the container runs as non-root user, the checkout might belows to a different user.

Example

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    container: votca/buildenv:latest
    steps:
      - uses: actions/checkout@master
        with:
          submodules: true
      - run: id
      - run: ls -l

The user is:

uid=1000(votca) gid=1000(votca) groups=1000(votca),10(wheel)

but the checkout is owned by uid 1001.

@junghans
Copy link
Author

Ok, I got it, the checkout is done outside of the container and hence owned by 1001, adding options: --user 1001 to the container: block, seems like a good workaround.

@ethomson
Copy link
Contributor

Glad you got this working - unfortunately, the docker containers can run as any user (as specified by the USER option in the Dockerfile) so there's very little control that we have over this. I'm going to close this issue, but if you have additional feedback, please see the GitHub Actions forum or contact us.

@junghans
Copy link
Author

The problem is that the workaround above leads to other issues as the special user in the container had sudo rights, but of course, using a different user will not have that anymore.

pexcn added a commit to pexcn/docker-images that referenced this issue Feb 16, 2021
pcolberg added a commit to pcolberg/fpga-runtime-for-opencl that referenced this issue Apr 15, 2022
… runners

This resolves a recent regression with GitHub-hosted runners where
actions/checkout@v2 fails to create a directory under /__w/_temp/

intel#104 (comment)

actions/checkout#47
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See actions/checkout#47

Change-Id: Ic0a8ac979ece73b0cca9465994365571a16b35e0
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: I9e0520626ca4090abeb519fb8cc04b92c8bf9c7c
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: I9e0520626ca4090abeb519fb8cc04b92c8bf9c7c
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: I9e0520626ca4090abeb519fb8cc04b92c8bf9c7c
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: Ib7ad629180ea26ca3a8a04160aded62af5bb9108
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: I5e6d09a48715b62e779713bddbe053cbbfd3e66c
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 15, 2022
See https://github.blog/2022-04-12-git-security-vulnerability-announced/

we're running as:

uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

See actions/checkout#47

Change-Id: I1dafea1d4ec80f072eab5fc0432b4d4dca110be1
pcolberg added a commit to intel/fpga-runtime-for-opencl that referenced this issue Apr 18, 2022
… runners

This resolves a recent regression with GitHub-hosted runners where
actions/checkout@v2 fails to create a directory under /__w/_temp/

#104 (comment)

actions/checkout#47
@0x2b3bfa0
Copy link

Relevant again after Git 2.35.2 safe.directory feature:

mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 19, 2022
In more recent versions, Git upstream does an owner check for the
top-level directory (see git upstream commit 8959555ce), also see
https://github.blog/2022-04-12-git-security-vulnerability-announced/

This change is included in git versions >=2.30.3, >=2.31.2, >=2.34.2,
>=2.35.2 + >=2.36.0-rc2, and therefore also affects the Git package
v2.35.2-1 as present in current Debian/unstable (as of 2022-04-15).

Now due to this behavioral change, our unit tests fail with e.g.:

| err        = ('fatal: unsafe repository '
|  "('/tmp/pytest-of-root/pytest-0/test_status_build0/ngcpctl-pytest-base/ngcp-config' "
|  'is owned by someone else)\n'
|  'To add an exception for this directory, call:\n'
|  '\n'
|  '\tgit config --global --add safe.directory '
|  '/tmp/pytest-of-root/pytest-0/test_status_build0/ngcpctl-pytest-base/ngcp-config\n')
| ex         = 128

We're creating many temporary git repositories. Therefore, adding every
single repository via `git config --global --add safe.directory` as
suggested in git's error message isn't really a viable option for us.

Git upstream also recognized this, and as of git rev 0f85c4a30 it's
possible to opt-out of this check via `safe.directory=*`.  This change
is currently included in Git versions 2.30.4, 2.31.3, 2.32.2, 2.33.3,
2.34.3 and 2.35.3 only, so not and option for the git version of
Debian/unstable, yet.

But nevertheless, it's not really an ideal option for us, as we don't
want to mess with $HOME/.gitconfig ever, as this might not always be
some random directory inside a testing container, but pointing to an
actual user configuration.

The underlying reason, why this issue showed up in our Github actions is
caused by the fact, that the checkout of the artifacts is running as
user (also see actions/checkout#47):

| uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

But the docker containers are executed with root permissions in the
following steps. To properly handle this, we set the permissions of the
git repository to $UID/$GID of the executing user.

Furthermore, we need to have proper author information available.
Otherwise it might be failing with `Author identity unknown [...] Please
tell me who you are` and fail with exit code 128 as well, as has been
observed in our Github's Debian packaging pipeline for sid.

While at it, let's unify our git configuration, by using the following
settings for all the user configuration:

| git config --local user.email pytest@example.com
| git config --local user.name pytest

Change-Id: Icad0ea4c3daf22f17481f23b27fa17750bd623da
mika added a commit to sipwise/ngcpcfg that referenced this issue Apr 19, 2022
In more recent versions, Git upstream does an owner check for the
top-level directory (see git upstream commit 8959555ce), also see
https://github.blog/2022-04-12-git-security-vulnerability-announced/

This change is included in git versions >=2.30.3, >=2.31.2, >=2.34.2,
>=2.35.2 + >=2.36.0-rc2, and therefore also affects the Git package
v2.35.2-1 as present in current Debian/unstable (as of 2022-04-16).

Now due to this behavioral change, our unit tests fail with e.g.:

| err        = ('fatal: unsafe repository '
|  "('/tmp/pytest-of-root/pytest-0/test_status_build0/ngcpctl-pytest-base/ngcp-config' "
|  'is owned by someone else)\n'
|  'To add an exception for this directory, call:\n'
|  '\n'
|  '\tgit config --global --add safe.directory '
|  '/tmp/pytest-of-root/pytest-0/test_status_build0/ngcpctl-pytest-base/ngcp-config\n')
| ex         = 128

We're creating many temporary git repositories. Therefore, adding every
single repository via `git config --global --add safe.directory` as
suggested in git's error message isn't really a viable option for us.

Git upstream also recognized this, and as of git rev 0f85c4a30 it's
possible to opt-out of this check via `git config --global --add
safe.directory *`. This change is currently included only in Git
versions 2.30.4, 2.31.3, 2.32.2, 2.33.3, 2.34.3 and 2.35.3, so not
available in Debian/unstable, yet.

But nevertheless, it's not really an ideal option for us, as we don't
want to mess with $HOME/.gitconfig ever, as this might not always be
some random directory inside a testing container, but pointing to an
actual user configuration.

The underlying reason, why this issue showed up in our Github actions is
caused by the fact, that the checkout of the artifacts is running as
user (also see actions/checkout#47):

| uid=1001(runner) gid=121(docker) groups=121(docker),4(adm),101(systemd-journal)

But the docker containers are executed with root permissions in the
following steps. To properly handle this, we set the permissions of the
git repository to $UID/$GID of the executing user.

Even more tricky and worth being aware of, certain git actions might
fail due to permission issues, without telling you directly:

| root@8d1e4156f6d8:/tmp# mkdir testrepo/
| root@8d1e4156f6d8:/tmp# cd testrepo/
| root@8d1e4156f6d8:/tmp/testrepo# git init
| Initialized empty Git repository in /tmp/testrepo/.git/
| root@8d1e4156f6d8:/tmp/testrepo# chown testbuild .
| root@8d1e4156f6d8:/tmp/testrepo# git config --local user.email pytest@example.com
| fatal: --local can only be used inside a git repository
| root@8d1e4156f6d8:/tmp/testrepo# echo $?
| 128
| root@8d1e4156f6d8:/tmp/testrepo# chown root .
| root@8d1e4156f6d8:/tmp/testrepo# git config --local user.email pytest@example.com
| root@8d1e4156f6d8:/tmp/testrepo# echo $?
| 0

While at it, let's unify our git configuration, by using the following
settings for all our user configuration:

| git config --local user.email pytest@example.com
| git config --local user.name pytest

Change-Id: Icad0ea4c3daf22f17481f23b27fa17750bd623da
@n1ngu
Copy link

n1ngu commented Feb 28, 2024

Main issue is the docker image might be engineered to work only for the non-root non-1001 user, e.g. meaningful files being owned by a given UID and present on a certain home which will NOT be the /github/home set by github actions.

My current workaround is

jobs:
  xxx:
    runs-on: ubuntu-latest
    container:
      image: MYIMAGE
      options: --user=root
    steps:
    - uses: actions/checkout@v4
    - name: Fix UID
      shell: bash
      run: |
        usermod --uid 1001 MYUSER
        find RELEVANT_PATHS -maxdepth 1 -uid OLDUID -exec chown --recursive --verbose 1001 '{}' ';'
        chown --recursive --verbose 1001 .  # fix checkout uid
    - name: Do something
      shell: su --preserve-environment MYUSER {0}
      run: |
        touch hello

Biggest issue so far is most actions aren't ready for this corner case and will run as root, so I'll be patching UIDs all along the workflow. I think this is beyond the scope of this action but I am uncertain about where to report it.

@n1ngu
Copy link

n1ngu commented Feb 28, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants