Jeff King wrote:
> On Fri, Jul 25, 2025 at 05:11:02PM +0100, Russell King (Oracle) wrote:
>
>> While I've been away on holiday over the last three weeks, my co-admin
>> updated ZenIV to Fedora 40, and now I find that git-daemon no longer
While this isn't relevant to the issue, it seems worth
noting that Fedora 40 went EOL a couple of months ago, so it
no longer receives any security updates. That's not ideal
if this system is not entirely internal. :)
>> exports my "public_git" directory. My attempts at debugging this have
>> failed - I tried adding strace to the git@.service but I get nothing.
>> This is a regression.
>
> I'm not aware of anything changing here recently, and ~user expansion
> does seem to work for me. E.g. using v2.49.0 and running:
>
> git daemon --base-path=/tmp/foo --export-all --user-path=public_git \
> --verbose --log-destination=stderr
>
> and then running:
>
> mkdir ~peff/public_git
> git init --bare ~peff/public_git/repo.git
> git -C ~peff/public_git/repo.git --work-tree=. commit --allow-empty -m foo
>
> git ls-remote git://localhost/~peff/repo.git
>
> works. I get a similar log message to you here:
I was curious, so I took Peff's recipe and gave it a try.
sudo dnf -y install git-daemon
sudo systemctl enable --now git.socket
mkdir ~/public_git
git init --bare ~/public_git/repo.git
git -C ~/public_git/repo.git --work-tree=. commit --allow-empty -m foo
sudo git config --system --add safe.directory ~/public_git/\*
git ls-remote git://localhost/~test/repo.git
And that fails as it does for Russell. I suspected SELinux,
which is enabled by default on Fedora. With luck, you have
not already ruled that out.
Two things were needed with respect to SELinux and one other
for basic permissions.
First, ensure the permissions on the home directory allow
access by others, as git-daemon will be running as nobody.
By default ~/ isn't searchable by others. (This isn't
likely the trouble in your case, but only because you'd
probably changed it well before the OS upgrade.)
# ensure ~ is searchable; git-daemon runs as nobody
chmod -c o=x ~
The permissions on ~/public_git and the subdirectories were
already okay, but if you set a strict umask, it might be
worth ensuring they're okay (also unlikely for you as this
worked before an upgrade).
Then ensure the SELinux context type is correct. It should
be git_user_content_t. You can add -n to the restorecon
call to see what it would change.
# The -F isn't strictly required, I just like setting
# the user, role, range portion as well as the type.
restorecon -FRv ~/public_git/
This is close, but still not enough as SELinux doesn't allow
git-daemon to search user home directories by default.
There is a boolean to enable that so you don't have to
create any custom policy. But for reference, audit2allow
tells you just that:
$ sudo ausearch -ts recent -m AVC | audit2allow
[... needless blank lines elided ...]
#============= git_system_t ==============
#!!!! This avc can be allowed using the boolean 'git_system_enable_homedirs'
allow git_system_t user_home_dir_t:dir search;
Enable the boolean:
sudo setsebool -P git_system_enable_homedirs=1
And `git ls-remote git://localhost/~test/repo.git` now
returns successfully. It's empty in this case, but I cloned
a repo with content into ~/public_git and confirmed it
worked as expected.
With luck, it's SELinux biting you (or, less likely) a
permission on ~ or ~/public_git and this will help.
It does seem like the git-daemon package in Fedora could use
a README-SELinux.md which explains this stuff, like the cgit
package. That might have helped you or others in getting
started.
--
Todd
