Git bug report - CNS - Shared repository permissions issues under RedHat 9

Hello Git,

Please, consider our bug report. Thank-you

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

We upgraded the operating system from RedHat Enterprise Linux 7 to 9. This upgrade pulled the version of Git from 1.8.3.1 to 2.43.5.

What did you expect to happen? (Expected behavior)

We expected to be able to continue using git in our shared repository normally.

What happened instead? (Actual behavior)

Since the upgrade, any clone attempt ends with

***

c:\tmp\gittest>git clone ssh://10.150.80.53/data/git/cns/repo-parent/repo.git Cloning into 'repo'... fatal: detected dubious ownership in repository at '/data/git/cns/repo-parent/repo.git' To add an exception for this directory, call:

        git config --global --add safe.directory /data/git/cns/repo-parent/repo.git
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists

***

Every repository we serve is already configured with the shareRepository directive set to true. This used to work fine before the OS upgrade:

[core]
  repositoryformatversion = 0
  filemode = true
  bare = true
  sharedRepository = true

Adding the safe.directory setting on a client basis does not make any difference, as the problem lies solely on the Git server.

The UNIX modes and ownership use the common setup with setgid (2770 permissions). Every user belongs to the group and is allowed to read and write with no exceptions. The effective permissions have been checked locally and via SSH and they work as expected. The system uses Centrify as the Microsoft Active Directory Domain Services client implementation, which was also upgraded alongside the operating system, but given the fact that the effective permissions work fine after the OS upgrade we came to the conclusion that, apparently, Git might be involved.

What's different between what you expected and what actually happened?

The inability to interact with Git as you can see in the error.

Anything else you want to add:

We think that we might be missing an additional configuration directive as required by the Git upgrade, but are unsure about it.

Please enquire for any additional information you might need.

Thank-you very much for your attention.

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.43.5 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.14.0-427.33.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 16 10:56:24 EDT 2024 x86_64 compiler info: gnuc: 11.4 libc info: glibc: 2.34 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks] not run from a git repository - no hooks to show

On Mon, Oct 14, 2024 at 12:07:07PM +0000, Jordi Balcells-Smith wrote:

Given that 1.8.3.1 was tagged sometime in June, 2013, I'd say that is quite the jump ;-).

This is intentional. Please see the documentation in git-config(1) on safe.directory for more information about what this check does and how to disable it (if you desire).

Thanks, Taylor

Hi Taylor,

Thanks for your prompt reply. Apologies for this being a support enquiry rather than bug report.

Yeah, it was quite a leap actually! I got confused between the core.sharedRepository and safe.directory settings.

Setting the latter in the server made it. I presume the intent of safe.directory is to have a more granular control in shared repos.

Thank-you very much,

Jordi Balcells-Smith Service support specialist - IT operations Community Network Services

-----Original Message-----
From: Taylor Blau <me@ttaylorr.com> 
Sent: Tuesday, October 15, 2024 1:32 AM
To: Jordi Balcells-Smith <Jsmith@cnsonline.net>
Cc: git@vger.kernel.org
Subject: Re: Git bug report - CNS - Shared repository permissions issues under RedHat 9

On Mon, Oct 14, 2024 at 12:07:07PM +0000, Jordi Balcells-Smith wrote:

Given that 1.8.3.1 was tagged sometime in June, 2013, I'd say that is quite the jump ;-).

This is intentional. Please see the documentation in git-config(1) on safe.directory for more information about what this check does and how to disable it (if you desire).

Thanks, Taylor