gitea: New git security policy `safe.directory` (eg: 1.16.6 docker image) makes pushing fails

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 solution: add to C:\Program Files\Git\etc\gitconfig

[safe]
	directory = *

It does not appear to. I also tried /data/git/* and that didn’t work either. After some research, the wildcard ability was added in 2.36 from what I can tell, the version of git running in my gitea container is 2.30.3. Maybe recursive is added as well.

Just encountered this issue myself. Running docker on Ubuntu Linux.

    volumes:
      - /mnt/data/gitea:/data
      - /mnt/RemoteStorage/repositories/gitea:/data/git/repositories
      - /mnt/RemoteStorage/repositories/gitea/lfs:/data/git/lfs

So I am mounting repositories and lfs from an NFS Share from TrueNAS:

192.168.1.100:/mnt/RemoteNAS/RemoteStorage /mnt/RemoteStorage nfs proto=tcp

This same filesystem is also shared to a Windows machine via an SMB share. For some reason adding directory = * under the [safe] section did not fix the issue, had to specify the exact path, so not ideal. I did notice a bunch of my repo dirs were owned by root. I did chown those to git (which is the user gitea was running under).

However, once I added the directory to safe, the new repo was created with root as the owner.

There is a transparent solution: setting safe.directory=* in customized git global config, then no security risk for Gitea internal usage, users do not need to do anything, Gitea doesn’t blow up it’s app.ini/settings, no need to update document, and from then on Gitea never pollute user’s git config again and again.

Hum, do you mean that after running docker exec gitea chown -R 1000 /data/git/repositories there still are files owned by root in this directory (which you can see by running docker exec gitea find /data/git/repositories ! -user 1000)? Or do you mean that despite all files being owned by user 1000 Gitea still complains with the same error whenever you try to push a commit?

Still same error. User ownership doesn’t matter to get this error either, I’ve tried repos with git and root user, the error is the same. And it indeed usualy changes on (failed, obviously) push from root to git.

git v2.35.2 1 was released and addresses two security issues CVE-2022-24765 and CVE-2022-24767. Bypassing the fix for these CVE would put users at risk.

I see no “risk” in a docker environment when bypassing these fixes. The CVEs are only relevant in multi-user system, while our docker environment is strictly single-user.

On second thought, I think as soon as the repos directory is volume-mounted to the outside, the system could be seen as multi-user. So concluding, I would advice to either:

• Preferably chown the files so they are owned by either git in rootless or root in rootful image
• If above is not possible, put below section into /etc/gitconfig and volume-mount that file into the container. This is the wildcard version of the workaround, I think it could also be to just the repository directory.

[safe]
	directory = *

git v2.35.2 1 was released and addresses two security issues CVE-2022-24765 and CVE-2022-24767. Bypassing the fix for these CVE would put users at risk.

I see no “risk” in a docker environment when bypassing these fixes. The CVEs are only relevant in multi-user system, while our docker environment is strictly single-user.

No. I run a docker image in macOS.

Did you try to chown -R 1000 the repositories directory?

I run Windows as host, this is not possible.

But the equivalent exists in windows via : properties -> security -> advance -> change owner And ticking the [x] replace all child object permission entries with inheritable permission entries from this object

Did you try to chown -R 1000 the repositories directory?

I run Windows as host, this is not possible.

Quick question, is this title really correct? From what I read its about git and not docker. So I suggest changing it.