That warning is specific to git-for-windows/git path.c, for any path starting with /
Trying instead the UNC path \\192.168.1.120\sambashare\x would result, as commente by the OP LNseyJt2X-24UJ4r7KTL, in:
fatal: bad config output.
Input it via git config produce something like \\\\192.168.1.120\\sambashare in the config file, which is not recognized.
Correct form, as illustrated in michaelosthege's answer is adding %(prefix)/ (not just %(prefix)) before the path:
%(prefix)///192.168.1.120/x
Or downgrade Git for Windows (if you really do not want to see this warning), since this message comes from the recent commit 66a6bcf for v2.35.2.windows.1:
mingw: deprecate old-style runtime-prefix handling in interpolate_path()
On Windows, an absolute POSIX path needs to be turned into a Windows
one.
We used to interpret paths starting with a single / as relative
to the runtime-prefix, but now these need to be prefixed with
%(prefix)/.
Let's warn for now, but still handle it.
Or upgrade to 2.5.3 (see below), and opt-out with safe.directory=*
This all comes from With Git 2.35.2 (Q1 2022):
See commit 6e7ad1e (27 Nov 2021) by Carlo Marcelo Arenas Belón (carenas).
See commit 53ef17d, commit 1f480d5, commit 4d0b43a, commit 93fbff0, commit 87ed4fc, commit 303b876, commit 9bcd7a8, commit 201b0c7, commit 44de39c, commit 6a2381a, commit cb95038, commit 2a9a586, commit 898225b (17 Mar 2022), commit fdcad5a (23 Mar 2022), and commit 8959555, commit bdc77d1 (02 Mar 2022) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit f1b50ec, 11 Apr 2022)
setup_git_directory(): add an owner check for the top-level directory
Signed-off-by: Johannes Schindelin
It poses a security risk to search for a git directory outside of the directories owned by the current user.
For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work.
Merely navigating to such a space with a Git-enabled PS1 when there is a maliciously-crafted /scratch/.git/ can lead to a compromised account.
The same holds true in multi-user setups running Windows, as C:\ is writable to every authenticated user by default.
To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user.
We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck.
This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users.
To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting safe.directory.
The safe.directory config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories.
We are particularly careful to provide a helpful message to any user trying to use a shared repository.
config now includes in its man page:
include::config/safe.txt[]
git config now includes in its man page:
safe.directory
These config entries specify Git-tracked directories that are
considered safe even if they are owned by someone other than the
current user. By default, Git will refuse to even parse a Git
config of a repository owned by someone else, let alone run its
hooks, and this config setting allows users to specify exceptions,
e.g. for intentionally shared repositories (see the --shared
option in git init).
This is a multi-valued setting, i.e. you can add more than one directory
via git config --add. To reset the list of safe directories (e.g. to
override any such directories specified in the system config), add a
safe.directory entry with an empty value.
This config setting is only respected when specified in a system or global
config, not when it is specified in a repository config or via the command
line option -c safe.directory=<path>.
The value of this setting is interpolated, i.e. ~/<path> expands to a
path relative to the home directory and %(prefix)/<path> expands to a
path relative to Git's (runtime) prefix.
CHANGES with 2.35.3 (Apr. 2022):
See commit d516b2d, commit 2f0dde7, commit 1f65dd6, commit 1530434, commit 09f66d6, commit 17083c7 (13 Apr 2022) by Junio C Hamano (gitster).
See commit 0f85c4a, commit e47363e (13 Apr 2022) by Derrick Stolee (derrickstolee).
See commit bb50ec3 (13 Apr 2022) by Matheus Valadares (Matheus28).
(Merged by Junio C Hamano -- gitster -- in commit 1ac7422, 13 Apr 2022)
setup: opt-out of check with safe.directory=*
Signed-off-by: Derrick Stolee
With the addition of the safe.directory in 8959555 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02, Git v2.36.0-rc2 -- merge) (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02) released in v2.35.2, we are receiving feedback from a variety of users about the feature.
Some users have a very large list of shared repositories and find it cumbersome to add this config for every one of them.
In a more difficult case, certain workflows involve running Git commands within containers.
The container boundary prevents any global or system config from communicating safe.directory values from the host into the container.
Further, the container almost always runs as a different user than the owner of the directory in the host.
To simplify the reactions necessary for these users, extend the definition of the safe.directory config value to include a possible '*' value.
This value implies that all directories are safe, providing a single setting to opt-out of this protection.
Note that an empty assignment of safe.directory clears all previous values, and this is already the case with the "if (!value || !*value)" condition.
git config now includes in its man page:
To completely opt-out of this security check, set safe.directory to the
string *. This will allow all repositories to be treated as if their
directory was listed in the safe.directory list. If safe.directory=*
is set in system config and you want to re-enable this protection, then
initialize your list with an empty value before listing the repositories
that you deem safe.
With Git 2.37 (Q3 2022), safe.directory is further clarified.
See commit 756d159, commit 424f315, commit f625639 (27 Apr 2022) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 1256a25, 20 May 2022)
safe.directory: document and check that it's ignored in the environment
Signed-off-by: SZEDER Gábor
The description of 'safe.directory' mentions that it's respected in the system and global configs, and ignored in the repository config and on the command line, but it doesn't mention whether it's respected or ignored when specified via environment variables (nor does the commit message adding 'safe.directory' from commit 8959555 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02, Git v2.36.0-rc2 -- merge)).
Clarify that 'safe.directory' is ignored when specified in the environment, and add tests to make sure that it remains so.
git config now includes in its man page:
config, not when it is specified in a repository config, via the command
line option -c safe.directory=<path>, or in environment variables.
With a recent update to refuse access to repositories of other people by default, "sudo make install" and "sudo git describe(man) stopped working.
This series intends to loosen it while keeping the safety with Git 2.37 (Q3 2022).
See commit b9063af, commit ae9abbb, commit 5f1a3fe (12 May 2022) by Carlo Marcelo Arenas Belón (carenas).
(Merged by Junio C Hamano -- gitster -- in commit 2088a0c, 26 May 2022)
git-compat-util: avoid failing dir ownership checks if running privileged
Reported-by: Guy Maurel
Helped-by: SZEDER Gábor
Helped-by: Randall Becker
Helped-by: Phillip Wood
Suggested-by: Johannes Schindelin
Signed-off-by: Carlo Marcelo Arenas Belón
bdc77d1 ("Add a function to determine whether a path is owned by the current user", 2022-03-02, Git v2.36.0-rc2 -- merge) checks for the effective uid of the running process using geteuid(), but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call:
guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
[sudo] password for guy:
fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)
Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead.
This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way.
Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID.
In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to happen and even if it does, the code would just mostly fail safely, so there was no attempt either to detect it or prevent it by the code, which is something that might change in the future, based on expected user feedback.
git config now includes in its man page:
As explained, Git only allows you to access repositories owned by
yourself, i.e. the user who is running Git, by default.
When Git
is running as 'root' in a non Windows platform that provides sudo,
however, git checks the SUDO_UID environment variable that sudo creates
and will allow access to the uid recorded as its value instead.
This is to make it easy to perform a common sequence during installation
"make && sudo make install".
A git process running under 'sudo' runs as 'root' but the 'sudo' command exports the environment variable to record
which id the original user has.
If that is not what you would prefer and want git to only trust
repositories that are owned by root instead, then you must remove
the SUDO_UID variable from root's environment before invoking git.
And:
With Git 2.37 (Q3 2022), sudo git foo used to consider a repository owned by the original user a safe one to access; it now also considers a repository owned by root a safe one, too (after all, if an attacker can craft a malicious repository owned by root, the box is 0wned already).
See commit 6b11e3d (17 Jun 2022) by Carlo Marcelo Arenas Belón (carenas).
(Merged by Junio C Hamano -- gitster -- in commit 694c0cc, 17 Jun 2022)
git-compat-util: allow root to access both SUDO_UID and root owned
Helped-by: Johanness Schindelin
Signed-off-by: Carlo Marcelo Arenas Belón
Previous changes introduced a regression which will prevent root for accessing repositories owned by thyself if using sudo because SUDO_UID takes precedence.
Loosen that restriction by allowing root to access repositories owned by both uid by default and without having to add a safe.directory exception.
git config now includes in its man page:
however, git checks the SUDO_UID environment variable that sudo creates and will allow access to the uid recorded as its value in addition to the id from 'root'.
