<metaname="description"content="If Gitea runs as user git, calls a patched Git version and a parent directory of the git repositories is owned by a user other than git, it will fail."/>
<metaproperty="og:description"content="If Gitea runs as user git, calls a patched Git version and a parent directory of the git repositories is owned by a user other than git, it will fail."/>
<p>April 12, 2022 version <ahref="https://lore.kernel.org/git/xmqqv8veb5i6.fsf@gitster.g/">git v2.35.2</a> was released and addresses a security issue <ahref="https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2">CVE-2022-24765</a>. It was backported to 2.30.3, v2.31.2, v2.32.1, v2.33.2, and v2.34.2 and published by distributions such as <ahref="https://security-tracker.debian.org/tracker/CVE-2022-24765">Debian GNU/Linux</a>, <ahref="https://www.alpinelinux.org/releases/">Alpine</a>.</p>
<p><strong>If Gitea runs as user <code>foo</code>, calls a patched Git version and a parent directory of the git repositories is owned by a user other than <code>foo</code>, it will fail</strong> with a message such as:</p>
<prestyle="background-color:#2b303b;color:#c0c5ce;"><code><span>Failed to open repository: Git/Data Error: exit status 128 - fatal: unsafe repository ('/data/git/repositories/git/data.git' is owned by someone else)
</span></code></pre>
<p>This started to show in the past few weeks to <ahref="https://github.com/go-gitea/gitea/issues/19455">users running the Gitea binary on Windows</a> who also independently installed git v2.36. And then to people running <ahref="https://github.com/go-gitea/gitea/issues/19455#issuecomment-1106331149">Gitea from snap</a>, on <ahref="https://github.com/go-gitea/gitea/issues/19455#issuecomment-1106312061">a Synology NAS</a> and then people running from <ahref="https://github.com/go-gitea/gitea/blob/main/Dockerfile#L2">Gitea docker images</a> which is based on <ahref="https://www.alpinelinux.org/releases/">Alpine</a>.</p>
<h3id="workarounds">Workarounds<aclass="zola-anchor"href="#workarounds"aria-label="Anchor link for: workarounds"
><spanclass="anchor-icon">#</span></a
>
</h3>
<ul>
<li>If using <ahref="https://hub.docker.com/r/gitea/gitea">Gitea docker images</a>:
<ul>
<li>upgrade to <ahref="https://github.com/go-gitea/gitea/pull/19876">Gitea >=1.16.9</a> or 1.17, both have git >=2.36</li>
<li>If the Gitea binary was installed independently of git, upgrade git to a version that is <ahref="https://git-scm.com/docs/git-config#Documentation/git-config.txt-safedirectory">greater or equal to 2.36</a> and disable the security check entirely with:
<ul>
<li>impersonate the <ahref="https://docs.gitea.io/en-us/install-from-binary/#recommended-server-configuration">user dedicated to Gitea</a> (usually git)</li>
<h3id="bug-fix">Bug fix<aclass="zola-anchor"href="#bug-fix"aria-label="Anchor link for: bug-fix"
><spanclass="anchor-icon">#</span></a
>
</h3>
<p>The <ahref="https://github.com/go-gitea/gitea/pull/19870">bug fix</a> is for Gitea to ensure <code>git config --global --replace-all safe.directory '*'</code> is set on its <ahref="https://docs.gitea.io/en-us/install-from-binary/#recommended-server-configuration">dedicated user</a> when it initializes. It is effective on the condition that the git CLI version is <ahref="https://git-scm.com/docs/git-config#Documentation/git-config.txt-safedirectory">greater or equal to 2.36</a>.</p>
<h3id="bug-fix-rationale">Bug fix rationale<aclass="zola-anchor"href="#bug-fix-rationale"aria-label="Anchor link for: bug-fix-rationale"
><spanclass="anchor-icon">#</span></a
>
</h3>
<p>It is safe to <ahref="https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/50/diffs">disable the security check in Gitea</a>. It is not vulnerable to <strong><ahref="https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2">CVE-2022-24765</a></strong> because it calls the git CLI <ahref="https://github.com/go-gitea/gitea/blob/main/modules/git/command.go#L160">after changing its working directory</a> to be the git repository targeted by the command (for instance <ahref="https://github.com/go-gitea/gitea/blob/main/modules/git/diff.go#L38-L45">diff</a>) or a temporary directory. Therefore <strong>it will not explore the parent directories looking for a git configuration file</strong>.</p>
<p>The security check is triggered because the repository is owned by an unexpected user (root instead of git typically) and <strong>not because a parent directory is owned by an unexpected user</strong>. This, in itself, is a problem worth investigating but it is unrelated and was revealed by the newer security check of git even though it does not match the threat described in <strong><ahref="https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2">CVE-2022-24765</a></strong>.</p>
<p>It appears non trivial to enforce a consistent ownership of files and directories, either within docker or outside docker when networked file systems are involved. The Gitea server was not troubled by this inconsistency so far because the permissions allow it to write and read where expected, regardless of the owner. It is not worth looking into but it is ancient and unrelated.</p>
<p>Gitea runs under a dedicated user, either when installed <ahref="https://docs.gitea.io/en-us/install-from-binary/#recommended-server-configuration">from binary</a> or from <ahref="https://docs.gitea.io/en-us/install-with-docker/">docker</a> and <ahref="https://github.com/go-gitea/gitea/blob/main/modules/git/git.go#L196-L207">modifies the global git configuration</a> depending on the git version at initialization time. Fixing the problem can therefore be done by <ahref="https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/50/diffs#bcd72ff867cbd1ddd5b6518c3a05b5f1a6021286_209_209">disabling the security check in the global git config file at initialization time</a>. It also requires a minimum version of git 2.36 to be installed, which is the case for Gitea docker images with <ahref="https://github.com/go-gitea/gitea/pull/19876">versions >= 1.16.9</a>.</p>
