[BUG?] git-daemon 2.49.0 in F40 no longer exports user directories

Hi,

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 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.

Having spent quite a while trying to get to the bottom of this and failing, I'm reaching out for some help - especially given the proximity of the kernel merge window opening this weekend.

The log indicates:

Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] Extended attribute "host": git.armlinux.org.uk Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] Extended attribute "protocol": version=2 Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] Request upload-pack for '~rmk/linux-arm.git/' Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] userpath <public_git>, request <~rmk/linux-arm.git/>, namlen 4, restlen 15, slash </linux-arm.git/> Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] '~rmk/public_git/linux-arm.git': not in directory list

It seems to detect that it's a user path, and adds the "public_git" --user-path to it, but it seems to fail to translate ~rmk into /home/rmk.

/etc/gitconfig contains:

[safe]
        directory = /var/lib/git/git.armlinux.org.uk/*
        directory = /home/rmk/public_git/*

and /lib/systemd/system/git@.service contains:

[Unit] Description=Git Repositories Server Daemon Documentation=man:git-daemon(1)

[Service]
User=nobody
ExecStart=-/usr/libexec/git-core/git-daemon --base-path=/var/lib/git --export-all \
          --user-path=public_git --inetd --log-destination=stderr --verbose
StandardInput=socket
StandardError=journal

Any ideas what is necessary to fix it?

Thanks.

On Fri, Jul 25, 2025 at 05:11:02PM +0100, Russell King (Oracle) wrote:

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:

That is, even though we print ~peff (or ~rmk), I think we still look for repos in /home/peff. E.g., if I strace and substitute "none.git" (to make the trace smaller, since we won't find a repo), I see it looking at:

  
  newfstatat(AT_FDCWD, "/home/peff/public_git/none.git/.git", 0x7ffc1cf9c8d0, 0) = -1 ENOENT (No such file or directory)
  newfstatat(AT_FDCWD, "/home/peff/public_git/none.git", 0x7ffc1cf9c8d0, 0) = -1 ENOENT (No such file or directory)
  newfstatat(AT_FDCWD, "/home/peff/public_git/none.git.git/.git", 0x7ffc1cf9c8d0, 0) = -1 ENOENT (No such file or directory)
  newfstatat(AT_FDCWD, "/home/peff/public_git/none.git.git", 0x7ffc1cf9c8d0, 0) = -1 ENOENT (No such file or directory)

If you strace, do you see similar stat calls?

But of course I don't get this log line:

which isn't too surprising since things succeed for me. But the "not in directory list" part is interesting. If we could not find the repo on disk, we get something more like:

  '~peff/public_git/none.git' does not appear to be a git repository

Looking through daemon.c:path_ok(), if we see the user-path expansion but not "does not appear to be a git repository", then we're getting hung up on this code:

          if ( ok_paths && *ok_paths ) {
                  const char **pp;
                  int pathlen = strlen(path);
  
                  /* The validation is done on the paths after enter_repo
                   * appends optional {.git,.git/.git} and friends, but
                   * it does not use getcwd().  So if your /pub is
                   * a symlink to /mnt/pub, you can include /pub and
                   * do not have to say /mnt/pub.
                   * Do not say /pub/.
                   */
                  for ( pp = ok_paths ; *pp ; pp++ ) {
                          int len = strlen(*pp);
                          if (len <= pathlen &&
                              !memcmp(*pp, path, len) &&
                              (path[len] == '\0' ||
                               (!strict_paths && path[len] == '/')))
                                  return path;
                  }
          }
          else {
                  /* be backwards compatible */
                  if (!strict_paths)
                          return path;
          }

My command line does not set --strict-paths, and neither does yours. So presumably you are stuck on the ok_paths. But those come from non-option paths on the git-daemon command line. My invocation does not pass any, and from what you wrote here:

neither do you. Is it possible that when invoking git-daemon, systemd is adding more arguments? Can you check with systemd logs or via strace (or maybe even ps, though I guess the process is short-lived in inetd mode)?

I'm not very familiar with systemd, but IIRC @-services are just templates that expect an argument. And in this case the argument is filled in when the git.socket service runs the git@ unit for a single connection. But I think that argument is only expanded by a %-placeholder, not shoved onto the ExecStart line.

So I dunno. I am just guessing at the systemd connection. But it seems like somehow an extra argument is ending up in your git-daemon invocation.

-Peff

PS My invocation above is obviously not running in --inetd mode like
   yours is, but I don't think that's the culprit. If I put this into
   /tmp/proxy:

     #!/bin/sh
     exec git daemon --base-path=/tmp/foo --export-all --inetd \
	--user-path=public_git --log-destination=stderr --verbose

  and then invoke it directly:

    git -c core.gitproxy=/tmp/proxy ls-remote git://localhost/~peff/repo.git

  it works the same.

  I also tried taking the FC40 git@.service and git.socket files and
  sticking them in my systemd setup, and it also seems to work. So I am
  all out of guesses.

Jeff King wrote:

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. :)

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.

On Sat, Jul 26, 2025 at 09:53:27AM -0400, Todd Zullinger wrote:

Interesting. That would explain why I didn't see the problem on my Debian system.

I am still puzzled why Russell would see the message he does, though. From my read of the code, seeing "not in directory list" but not seeing "...does not appear to be a git repository" implies that enter_repo() succeeds, but ok_paths is non-empty and forbids it.

Probably not that important if your suggestions here solve his problem. But of course if you can easily satisfy my curiosity by running through a debugger, I'd be happy. ;)

It might just be that I'm mis-reading the code.

-Peff

On Sun, Jul 27, 2025 at 02:45:42AM -0400, Jeff King wrote:

Yes, I had an override in systemd that I'd forgotten about to work around a previous issue (because the previous version we had on the machine required the paths on the end of the git-daemon command line.)

I wonder if there was a bug - --export-all broke, and then required the directories to be listed, and now it's been "fixed" and now the listed directories become a list of those to exclude?

The override.conf had something like:

ExecStart=-/usr/libexec/git-core/git-daemon --export-all \
  --user-path=public_git --inetd --log-destination=stderr --verbose \
    --interpolated-path='/var/lib/git/%%H%%D' \
    /var/lib/git/git.armlinux.org.uk \
    /home/rmk/public_git

I can't remember exactly now as I've deleted the last two paths, and added --base-path=/var/lib/git - and now it's working.