Downside of tightened file validations of v2.55 - UNC path user permissions either too tightly or not being checked at all anymore

[Marcel-4210]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

2.55

Windows version

Other

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.20348.5386]

== Windows Server 2022 with Remote Desktop Services aka. Terminal Server / Multi-User-Environment

Options set during installation

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: FFOnly
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

• Mixed environment of Windows and Linux Servers
• NetApp mapping Windows- and Linux-Users when accessing network shares
• Developers using network shares (mixed CIFS/SMB and NFS) regularly to work on the same checked out repositories but using different Client Machines
• Developers also regularly helping each other and thus viewing/editing other user's files (carefully keeping file ownerships within git directories intact)

I am aware that the whole "check out repository once, edit on multiple Clients with different platforms" is not an ideal working state, but I also couldn't yet successfully convince our developers to change that behavior... It simplifies a couple things for them and saves them a lot of time for several reasons.

Terminal/shell

CMD

Commands that trigger the issue

# drive Q:\ is a mapped Network Share pointing to \\storage.domain.zz\share)
q:
git clone git@github.com:xxx/IAC.git
cd IAC
git status

Expected behaviour

Before 2.55, the users name / SID was checked in a way, that a similar error showed up in case the directory was owned by a different user. This was expected and good.

Since 2.55, git seems to skip that check entirely when the work directory is a network share. Git Release notes state:

Following [TortoiseGit v2.19](https://groups.google.com/g/tortoisegit-announce/c/31zdmOBi4vY), .git file validations have been tightened. As a consequence, access to remote repositories via UNC file paths needs to be allowed explicitly via the safe.directory configuration.

As far as I understand the only solution would be a configuration file change like this (either for the whole share or for single repositories on it):

[safe]
	directory = //storage.domain.zz/IAC
	directory = //storage.domain.zz/*

Unfortunately, that disables these checks entirely and users wouldn't notice anymore, when they accidentally work in another user's directory.

Is there a middle way (available or planned) to restore the functionality of pre 2.55 permission checks on network shares?

Actual behaviour

fatal: detected dubious ownership in repository at '//storage.domain.zz/IAC'
'//storage.domain.zz/IAC' may refer to a non-local directory
To add an exception for this directory, call:

        git config --global --add safe.directory '%(prefix)///storage.domain.zz/IAC'

Repository

No response

[dscho]

As far as I understand the only solution would be a configuration file change like this (either for the whole share or for single repositories on it):

[safe]
	directory = //storage.domain.zz/IAC
	directory = //storage.domain.zz/*

The idea was that only the first directory line is required. You're right that the second one would disable the checks for other directories. Does it not work if you skip the last line?