git/Documentation/config/safe.txt

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 linkgit:git-init[1]).
+
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.
+
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.
setup_git_directory(): add an owner check for the top-level directory 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. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2022-03-02 11:23:04 +00:00			`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 linkgit:git-init[1]).`
			`+`
			`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.`
setup: opt-out of check with safe.directory=* With the addition of the safe.directory in 8959555ce (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. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2022-04-13 15:32:31 +00:00			`+`
			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.`