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

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

[Russell King (Oracle)]

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Jeff King]

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

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

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:

> Jul 25 16:56:55 ZenIV git-daemon[4046439]: [4046439] '~rmk/public_git/linux-arm.git': not in directory list

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:

> 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

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.

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

[Todd Zullinger]

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

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

[Jeff King]

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

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

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

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

[Russell King (Oracle)]

On Sun, Jul 27, 2025 at 02:45:42AM -0400, Jeff King wrote:
> On Sat, Jul 26, 2025 at 09:53:27AM -0400, Todd Zullinger wrote:
> 
> > 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.
> 
> 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.

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!