New git security policy safe.directory (eg: 1.16.6 docker image) makes pushing fails
#19455
Comments
|
Related: https://github.blog/2022-04-12-git-security-vulnerability-announced/ What is the ownership of |
It's running under Docker and it's created by Docker. Ownership just seems the default inherited stuff from Windows. |
|
Maybe it's something specific to Windows, but I doubt it. You could check by obtaining a shell inside the container. I guess we either need to fix file permissions or perform a workaround using |
|
Here is the output from ls -l inside docker: /data/git # ls -l
total 0
drwxrwxrwx 1 root root 0 Nov 23 19:24 lfs
drwxrwxrwx 1 git git 0 Feb 8 12:11 repositoriesAlso all repositories have git as owner. |
|
Can you also show permissions on |
|
Here: /data/git/repositories/git/data.git # ls -l
total 26
-rwxr-xr-x 1 git git 23 Mar 18 10:20 HEAD
drwxrwxrwx 1 root root 0 Mar 18 10:15 branches
-rwxr-xr-x 1 git git 86 Mar 18 10:15 config
-rwxr-xr-x 1 root root 73 Mar 18 10:15 description
drwxrwxrwx 1 root root 8192 Mar 18 10:15 hooks
drwxrwxrwx 1 root root 0 Apr 14 08:40 info
drwxrwxrwx 1 git git 16384 Apr 14 08:40 objects
drwxrwxrwx 1 git git 0 Mar 18 10:15 refs/data/git/repositories/git # ls -l
total 76
drwxrwxrwx 1 git git 4096 Feb 28 13:48 old.git
drwxrwxrwx 1 git git 4096 Apr 14 08:40 data.git
(cut down this list, all repos are the same except for the name / date)/data/git/repositories # ls -l
total 4
drwxrwxrwx 1 git git 4096 Apr 1 14:43 git/data/git # ls -l
total 0
drwxrwxrwx 1 root root 0 Nov 23 19:24 lfs
drwxrwxrwx 1 git git 0 Feb 8 12:11 repositories |
|
Hmm, this mix of |
|
Which image did you use? The rootless one? |
Also the case with 1.16.5, which works OK. Same "structure" is created on my local machine.
No, the normal one. image: gitea/gitea:1.16.5 |
|
I think the issue is that As for a fix, I see two options:
|
In fact the I think we need more information here. What is your docker compose file? How are you running git? How are you mapping the repositories on to docker? How are you pushing? Over HTTP or SSH? Why are these git repositories partially owned by root and partially by git? That is going to cause HUGE problems and I'm kinda surprised that this has ever worked. |
No, never, only the normal git image.
version: "3"
services:
gitea:
image: gitea/gitea:1.16.5
restart: always
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- DISABLE_REGISTRATION=true
- REQUIRE_SIGNIN_VIEW=true
- LOGIN_REMEMBER_DAYS=31
- SESSION_LIFE_TIME=2678400
- APP_NAME=Gitea
- DISABLE_SSH=true
- SECRET_KEY=redacted
- ROOT_URL=https://redacted.com:4040/
restart: always
volumes:
- ./data/git:/data/git
- ./data/gitea:/data/gitea
ports:
- "3000:3000"
See above.
HTTPS.
No idea, in 1.16.5 this works OK. What should it be owned by? I can try chown. |
|
Alright, I've been further testing this out. When starting gitea (restart docker), everything is on root. I tried to chown to git user, but everything stays on root. On 1.16.5 when pushing, some files and directories get changed from root to git. On 1.16.6 everything stays on root. |
|
Yeah, I'm having the same problem after update running Gitea in Docker on my Synology NAS. |
|
I can confirm the bug as well. No Push/Pull possible (unsafe repository ... is owned by someone else). Running on Ubuntu Server I installed gitea via snap. As this auto-updates applications (which I did not know), today all our repositories were producing an error 500. Reverting to the previous version (1.16.5) via "snap revert gitea" fixed the problem. |
|
In my case, chown was changed to 1026:users instead of git:git in some repositories. Login to SSH and change them back to git:git solved the issue. |
|
Same issue for me on Also have an Error 500 when open it in Gitea web UI. There is error in Gitea logs about Unlike other repositories which are OK, in advanced security of the folder of the broken repo, the owner (
Changing it solves my issue.
Hope it helps ! |
|
@Jimskapt - I see the same on windows server but it is clearly linked to git-scm 2.36.0 vs. 2.35.1. The version of gitea does not matter (I am using gitea-1.16.6). With git-scm 2.35.1 all repos can be opened, but with 2.36.0 accessing older ones gives a 500 error. |
I confirm. I've tried to revert back to some previous versions of Gitea (and some previous data backups) but keep git-scm unchanged, and still have the issue 😉 |
|
Quick question, is this title really correct? From what I read its about git and not docker. So I suggest changing it. |
|
We should probably just add |
|
I seriously suspect that this an issue to do with mapping of the drives and ownership of the gitea-repositories in the container, as compared to that on the host. Gitea and Git in the container needs all of its repos owned by the user it is running under - often the The first step would be to ensure that ALL of Gitea's files and repositories are owned by the user running Gitea (on the container). You need to check that the mapping of the Gitea user from the container to the host is correct. There should be an option in your compose file relating to users and mapping and docker configuration to ensure that users are appropriate mapped across. @Nuklon your What user is running |
Container, I run Windows as host so no ls :) Previous versions worked OK (and still work OK).
git |
|
WinServer 2019 + gitia 1.16.6 amd64 (with out gogit) + git 2.36.0.windows.1 = Error 500 in Web UI or error push 128 |
|
@techknowlogick PS: #19492 - loop link to here again! |
lunny
added
the
type/upstream
|
Got this problem on Gitea running as a Docker container on Linux on v1.16.7. Tried adding the repositories to global via the CLI for the container, but doesn't seem to change behaviour from Gitea. However, the line is definitely in the global config, have confirmed it. Also tried adding On a whim, I decided to try manually adding the lines to Not sure what the problem is. |
That's probably because
|
|
These problems are caused because git now requires that the repositories it is run in are owned by the user that runs git. In fact, Gitea has always required its repositories to be owned by the user that runs Gitea. That you were able to run with these configurations before was simply due to permissive permissions or failed ownership mapping. If you set up the user mapping correctly in docker these problems should go away and you will not require |
|
At least for Kubernetes it is not possible to change the UID mapping of the git user. The current mapping system only allows for processes (gitea) to be forced to run using a certain UID and GID. However, this does not change the UID or GID of the git user, which is permanently set during the image building process. Since I am using an NFS mapped volume for the git repositories and currently no plugin allows for UID mapping (kubernetes-sigs/nfs-subdir-external-provisioner#173), I have to alter the Dockerfile in order to permanently set the UID and GID of the git user to match with the NFS config. This is not really a great solution since it prevents me from using any official images and I have to build the image myself. The other solution of using an init script to alter the UID and GID of the git user at startup requires root permissions, which are not allowed due to a security policy in the namespace I run gitea in. Disabling the git safe directoy check seems to be the preferred solution here until there are better NFS plugins for Kubernetes or another solution is found. |
|
In the docker you can set the chosen $USER, $USER_GID and $USER_UID through the environment this changes the user that gitea will run as. gitea/docker/root/usr/bin/entrypoint Lines 9 to 31 in 1d04e86 In the rootless I think you can just use the |
It's just default stuff, I haven't changed anything and it's not working. |
That will only change the UID of the process not of the git user 😢 |
|
The UID of the process is all that matters. |
You definitely have some configuration. I think it's very clear that you must be mounting some volumes, otherwise you would not be seeing this. The mapping of the uids/gids in those volumes to docker is resulting in Gitea's repositories not being owned by the Gitea user. git is now enforcing that these repositories have to be owned by the running process. There is a mismapping - for whatever reason. That leaves the following solutions:
If those are too difficult or not successful:
[safe]
directory = *
Now, we as a project are considering adding that safe.directory setting by default - but we need to be clear why we're needing to add this and that it actually works. |
|
Of course I am mounting volumes. My docker-compose file is as follows (basically from https://docs.gitea.io/en-us/install-with-docker/#basics): version: "3"
services:
gitea:
image: gitea/gitea:1.16.5
restart: always
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- DISABLE_REGISTRATION=true
- REQUIRE_SIGNIN_VIEW=true
- LOGIN_REMEMBER_DAYS=31
- SESSION_LIFE_TIME=2678400
- APP_NAME=Gitea
- DISABLE_SSH=true
- SECRET_KEY=REDACTED
- ROOT_URL=REDACTED
restart: always
volumes:
- ./data/git:/data/git
- ./data/gitea:/data/gitea
ports:
- "3000:3000"I have nothing changed in the container.
Yes, that is not working. Specifying the full path in /etc/gitconfig does work, similar to #19455 (comment). I think git needs to be updated to allow wildcard support as the one shipped with image is 2.30.3 while wildcard is only added in 2.35.1 (?). |
environment:
- USER_UID=1000
- USER_GID=1000means that Gitea will be running as UID:1000 in the container. That means repositories in that /data/git must be owned by UID:1000 in the container. Let's work through this step-by-step (people running docker for windows can probably just jump to step 4 - presumably this includes you @Nuklon.)
docker exec -it <YOUR_CONTAINER_NAME> bash -i -c 'chown -R 1000:1000 /data/git'(I would hope that this has already been tried.) After running this check if the chown has applied, if so stop and try again. If you're getting problems then you may need to chown /data/gitea too, or change where your temporary files are being created.
sudo chown -R 1000:1000 /data/git(I don't think this would succeed where 1. above does not work but it's worth a try.) Again check if this has succeeded...
To solve this means that you need to look at how you're mounting these drives in your host system.
services:
gitea:
image: gitea/gitea:1.16.5
restart: always
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- DISABLE_REGISTRATION=true
- REQUIRE_SIGNIN_VIEW=true
- LOGIN_REMEMBER_DAYS=31
- SESSION_LIFE_TIME=2678400
- APP_NAME=Gitea
- DISABLE_SSH=true
- SECRET_KEY=REDACTED
- ROOT_URL=REDACTED
restart: always
volumes:
- git-dir:/data/git
- gitea-dir:/data/gitea
ports:
- "3000:3000"
volumes:
git-dir:
driver_opts:
type: cifs
o: "uid=1000,gid=1000"
device: "//localhost/$C/PATH/TO/DATA/GIT"
gitea-dir:
driver_opts:
type: cifs
o: "uid=1000,gid=1000"
device: "//localhost/$C/PATH/TO/DATA/GITEA"
#!/bin/bash
apk add git --repository=http://dl-cdn.alpinelinux.org/alpine/v3.16/main
/bin/s6-svscan /etc/s6Then on startup git will be updated from alpine 3.16 and a But in reality you should get it so that repos are owned by the Gitea user - and assuming you're a customer of Docker-Desktop you should pressure docker to make this easier to do on Windows. Honestly I've just spent far too long learning about how Docker - a thing I barely use - mounts volumes on Windows - an operating system I don't use. |
|
Just going by the steps.
I'll try to find some time next week to give dev a try. |
services:
gitea:
image: gitea/gitea:1.16.5
restart: always
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- DISABLE_REGISTRATION=true
- REQUIRE_SIGNIN_VIEW=true
- LOGIN_REMEMBER_DAYS=31
- SESSION_LIFE_TIME=2678400
- APP_NAME=Gitea
- DISABLE_SSH=true
- SECRET_KEY=REDACTED
- ROOT_URL=REDACTED
restart: always
volumes:
- git-dir:/data/git
- gitea-dir:/data/gitea
ports:
- "3000:3000"
volumes:
git-dir:
driver_opts:
type: cifs
o: "uid=1000,gid=1000"
device: "//localhost/$C/PATH/TO/DATA/GIT"
gitea-dir:
driver_opts:
type: cifs
o: "uid=1000,gid=1000"
device: "//localhost/$C/PATH/TO/DATA/GITEA"Or do 5-6. I've spent literally HOURS looking into this, writing "it worked before" is beyond infuriating. I know it worked before. We already know why it's not working. Git has changed to disallow using repositories that are not owned by the process that is running it and your configuration is not mounting volumes with the correct ownership. There are two ways of solving this:
One useful thing I've learnt from this is that we simply cannot trust file ownership on docker for windows. It's almost always going to be a lie and unhelpful to rely on simply because docker for windows has such a poor mechanism mounting volumes based on windows drives. We're going to have to make sure that we don't rely on this as if we do we're going to have explicitly un-support docker for windows. (This is of course ridiculous. Utterly and completely ridiculous.) This means that we're going to have to add safe.directory to at least our docker builds or take time to explain how to map users in our documentation. |
That wasn't meant that way, sorry. I appreciate the help here 🙂 What I don't quite understand is how in older versions git is changing ownership from root to git user on push, but that chown isn't working. What is git doing? |
|
I have updated to 1.16-dev and added [safe]
directory = *to /data/git/.gitconfig This works! 🎉 |
|
It also seems to work in WSL2 without adding safe directory (YMMV). WSL1 I could only get to work with the above change. |
Allow git push to work when networked file systems with mixed ownership are used with Gitea docker images >= 1.16.6 or Gitea binaries running alongside git versions published after 04/2022. There are circumstances independent of Gitea (networked file systems with various permission systems) by which the git repositories managed by Gitea may have mixed owners. It is not a behavior that Gitea have control over nor is it a problem as long as the permissions for Gitea to operate are correct. Gitea instances have been operating under these conditions for a number of years. It is detected as a potential security risk ( see GHSA-vw2c-22j4-2fh2 ) by the most recent git versions. However, Gitea always runs git commands with a current directory matching the repository on which it operates. That makes Gitea immune from this security problem and it is safe to ignore the mixed owner permission check. This gitconfig modification is done on a file dedicated to the user exclusively used by Gitea. Fixes: go-gitea#19455
Allow git push to work when networked file systems with mixed ownership are used with Gitea docker images >= 1.16.6 or Gitea binaries running alongside git versions published after 04/2022. There are circumstances independent of Gitea (networked file systems with various permission systems) by which the git repositories managed by Gitea may have mixed owners. It is not a behavior that Gitea have control over nor is it a problem as long as the permissions for Gitea to operate are correct. Gitea instances have been operating under these conditions for a number of years. It is detected as a potential security risk ( see GHSA-vw2c-22j4-2fh2 ) by the most recent git versions. However, Gitea always runs git commands with a current directory matching the repository on which it operates. That makes Gitea immune from this security problem and it is safe to ignore the mixed owner permission check. This gitconfig modification is done on a file dedicated to the user exclusively used by Gitea. Fixes: #19455 Co-authored-by: wxiaoguang <[email protected]> Co-authored-by: zeripath <[email protected]>
Allow git push to work when networked file systems with mixed ownership are used with Gitea docker images >= 1.16.6 or Gitea binaries running alongside git versions published after 04/2022. There are circumstances independent of Gitea (networked file systems with various permission systems) by which the git repositories managed by Gitea may have mixed owners. It is not a behavior that Gitea have control over nor is it a problem as long as the permissions for Gitea to operate are correct. Gitea instances have been operating under these conditions for a number of years. It is detected as a potential security risk ( see GHSA-vw2c-22j4-2fh2 ) by the most recent git versions. However, Gitea always runs git commands with a current directory matching the repository on which it operates. That makes Gitea immune from this security problem and it is safe to ignore the mixed owner permission check. This gitconfig modification is done on a file dedicated to the user exclusively used by Gitea. Fixes: go-gitea#19455 Co-authored-by: wxiaoguang <[email protected]> Co-authored-by: zeripath <[email protected]>
Allow git push to work when networked file systems with mixed ownership are used with Gitea docker images >= 1.16.6 or Gitea binaries running alongside git versions published after 04/2022. There are circumstances independent of Gitea (networked file systems with various permission systems) by which the git repositories managed by Gitea may have mixed owners. It is not a behavior that Gitea have control over nor is it a problem as long as the permissions for Gitea to operate are correct. Gitea instances have been operating under these conditions for a number of years. It is detected as a potential security risk ( see GHSA-vw2c-22j4-2fh2 ) by the most recent git versions. However, Gitea always runs git commands with a current directory matching the repository on which it operates. That makes Gitea immune from this security problem and it is safe to ignore the mixed owner permission check. This gitconfig modification is done on a file dedicated to the user exclusively used by Gitea. Fixes: go-gitea#19455 Co-authored-by: wxiaoguang <[email protected]> Co-authored-by: zeripath <[email protected]>
#42) * OCP4 updates * Trying w updated Node version * Updating reference to Artifactory (sub-folder) * Resolving 'Error shutting down storage: A layer is mounted: layer is in use by a container' issue * Downgrading to go version pre-v18, to workaround go-gitea/gitea#19455 * Confirmed local workaround to Go V18+, now testing on OpenShift v4 * Moved SMTP override sed statement to after 'copy fider .' * Trying again to debug 'layer is in use by a container' * Debugging 2 * Debugging 3 * Debug mode enabled * Updated fo OCP4 and SSO Shared Realm
Description
Since upgrading to 1.16.6, every push fails with the following error:
In docker console this is logged:
Downgrading to 1.16.5 makes it work again. UI works in 1.16.6 and also allows me to browse the files in this repository (or any other, all have this push error).
Gitea Version
1.16.6
Can you reproduce the bug on the Gitea demo site?
No
How are you running Gitea?
Windows Server 2022 + Docker. Windows 10 + Docker has the same problem.
The text was updated successfully, but these errors were encountered: