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

[Nuklon]

Description

Since upgrading to 1.16.6, every push fails with the following error:

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks push -v origin master:master
fatal: credential-cache unavailable; no unix socket support
POST git-receive-pack (2733 bytes)
remote: 
remote: Gitea: Internal Server Error        

In docker console this is logged:

Failed to open repository: Git/Data Error: exit status 128 - fatal: unsafe repository ('/data/git/repositories/git/data.git' is owned by someone else)

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.

[silverwind]

Related: https://github.blog/2022-04-12-git-security-vulnerability-announced/

What is the ownership of /data/git/repositories and does it differ from the user that is used to run git?

[Nuklon]

Related: https://github.blog/2022-04-12-git-security-vulnerability-announced/

What is the ownership of /data/git/repositories and does it differ from the user that is used to run git?

It's running under Docker and it's created by Docker. Ownership just seems the default inherited stuff from Windows.

[silverwind]

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 git config --global --add safe.directory /data/git as part of the docker build.

[Nuklon]

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 repositories

Also all repositories have git as owner.

[silverwind]

Can you also show permissions on /data/git/repositories/git/data.git and the parent directories up to /data/git?

[Nuklon]

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

[silverwind]

Hmm, this mix of git/root ownership looks odd, but it's probably not the cause of the error. owned by someone else implies the git process runs as someone else besides git which I think should not be possible if it's started as a child process of gitea ran as git.

[lunny]

Which image did you use? The rootless one?

[Nuklon]

Hmm, this mix of git/root ownership looks odd, but it's probably not the cause of the error. owned by someone else implies the git process runs as someone else besides git which I think should not be possible if it's started as a child process of gitea ran as git.

Also the case with 1.16.5, which works OK. Same "structure" is created on my local machine.
What's also odd is that the web-UI works fine and can browse the files correctly, shouldn't that also fail then? Not sure how that's read.

Which image did you use? The rootless one?

No, the normal one. image: gitea/gitea:1.16.5

[silverwind]

I think the issue is that git runs as root, but files are for some reason owned by git which the git 2.35.2 and above with the fix see as "unsafe". Did you ever run the rootless image before?

As for a fix, I see two options:

• adjust safe.directory which should restore behaviour with git versions before 2.35.2 but there might still be issues with writing files when a users switches from rootful to rootless image. git 2.36.0 added a * option to regard all directories as "safe" and I think that would be feasible for the docker image as it's essentially a single-user system.
• chown all files to the user that will run the app, this has the drawback of impacting startup performance with many repos but will allow switching between rootless and rootful images without issues.

[zeripath]

Hmm, this mix of git/root ownership looks odd, but it's probably not the cause of the error. owned by someone else implies the git process runs as someone else besides git which I think should not be possible if it's started as a child process of gitea ran as git.

In fact the lfs directories being owned by root imply that the gitea binary is not being run as the git user. Which is highly abnormal and deeply suspect.

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.

[Nuklon]

Did you ever run the rootless image before?

No, never, only the normal git image.

What is your docker compose file?

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"

How are you running git? How are you mapping the repositories on to docker?

See above.

How are you pushing? Over HTTP or SSH?

HTTPS.

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 idea, in 1.16.5 this works OK. What should it be owned by? I can try chown.

[Nuklon]

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.

[maxiorel]

Yeah, I'm having the same problem after update running Gitea in Docker on my Synology NAS.