safe.directory wildcards

safe.directory wildcards

[Stefan Metzmacher]

Hi,

given the recent importance of safe.directory, it would be great to
have something like '/data/git/*' to be supported, not just a single '*'
for a server that serves a lot of public git repositories owned by different owners.

Thanks for taking care of security problem, even if the fixes sometimes
have unexpected site effects...

metze

Re: safe.directory wildcards

[Junio C Hamano]

Stefan Metzmacher <metze@samba.org> writes:

> given the recent importance of safe.directory, it would be great to
> have something like '/data/git/*' to be supported, not just a single '*'
> for a server that serves a lot of public git repositories owned by different owners.

Interesting.

The original commit that introduced the '*' opt-out, 0f85c4a3
(setup: opt-out of check with safe.directory=*, 2022-04-13), was
done to specifically help those who have a large list of shared
repositories.  We could have moved all the way to allow globs back
then, and the possibility certainly was brought up.

  https://lore.kernel.org/git/xmqqk0bt9bsb.fsf@gitster.g/

But the loosening was done in a context of "brown paper bag fix"
so it is very much understandable that we did the simplest and most
obvious thing to avoid making silly mistakes in a haste.

I am reluctant to use wildmatch() but I would expect that in
practice "leading path matches" (in other words, "everything under
this directory is OK") is sufficient, perhaps?

------- >8 ------------- >8 ------------- >8 -------
Subject: safe.directory: allow "lead/ing/path/*" match

When safe.directory was introduced in v2.30.3 timeframe, 8959555c
(setup_git_directory(): add an owner check for the top-level
directory, 2022-03-02), it only allowed specific opt-out
directories.  Immediately after an embargoed release that included
the change, 0f85c4a3 (setup: opt-out of check with safe.directory=*,
2022-04-13) was done as a response to loosen the check so that a
single '*' can be used to say "I trust all repositories" for folks
who host too many repositories to list individually.

Let's further allow people to say "everything under this hierarchy
is deemed safe" by specifying such a leading directory with "/*"
appended to it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/safe.txt |  3 ++-
 setup.c                       | 24 +++++++++++++++++-------
 t/t0033-safe-directory.sh     | 15 +++++++++++++++
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git c/Documentation/config/safe.txt w/Documentation/config/safe.txt
index 577df40223..2d45c98b12 100644
--- c/Documentation/config/safe.txt
+++ w/Documentation/config/safe.txt
@@ -44,7 +44,8 @@ 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.
+that you deem safe.  Giving a directory with `/*` appended to it will
+allow access to all repositories under the named directory.
 +
 As explained, Git only allows you to access repositories owned by
 yourself, i.e. the user who is running Git, by default.  When Git
diff --git c/setup.c w/setup.c
index 9247cded6a..83c4ea44cd 100644
--- c/setup.c
+++ w/setup.c
@@ -1177,13 +1177,23 @@ static int safe_directory_cb(const char *key, const char *value,
 	} else if (!strcmp(value, "*")) {
 		data->is_safe = 1;
 	} else {
-		const char *interpolated = NULL;
-
-		if (!git_config_pathname(&interpolated, key, value) &&
-		    !fspathcmp(data->path, interpolated ? interpolated : value))
-			data->is_safe = 1;
-
-		free((char *)interpolated);
+		const char *allowed = NULL;
+
+		if (!git_config_pathname(&allowed, key, value)) {
+			size_t len;
+
+			if (!allowed)
+				allowed = value;
+			if (ends_with(allowed, "/*")) {
+				len = strlen(allowed);
+				if (!fspathncmp(allowed, data->path, len - 1))
+					data->is_safe = 1;
+			} else if (!fspathcmp(data->path, allowed)) {
+				data->is_safe = 1;
+			}
+		}
+		if (allowed != value)
+			free((char *)allowed);
 	}
 
 	return 0;
diff --git c/t/t0033-safe-directory.sh w/t/t0033-safe-directory.sh
index 11c3e8f28e..5fe61f1291 100755
--- c/t/t0033-safe-directory.sh
+++ w/t/t0033-safe-directory.sh
@@ -71,7 +71,22 @@ test_expect_success 'safe.directory=*, but is reset' '
 	expect_rejected_dir
 '
 
+test_expect_success 'safe.directory with matching glob' '
+	git config --global --unset-all safe.directory &&
+	p=$(pwd) &&
+	git config --global safe.directory "${p%/*}/*" &&
+	git status
+'
+
+test_expect_success 'safe.directory with unmatching glob' '
+	git config --global --unset-all safe.directory &&
+	p=$(pwd) &&
+	git config --global safe.directory "${p%/*}no/*" &&
+	expect_rejected_dir
+'
+
 test_expect_success 'safe.directory in included file' '
+	git config --global --unset-all safe.directory &&
 	cat >gitconfig-include <<-EOF &&
 	[safe]
 		directory = "$(pwd)"

Re: safe.directory wildcards

[Konstantin Ryabitsev]

On Wed, May 29, 2024 at 09:02:16AM GMT, Junio C Hamano wrote:
> When safe.directory was introduced in v2.30.3 timeframe, 8959555c
> (setup_git_directory(): add an owner check for the top-level
> directory, 2022-03-02), it only allowed specific opt-out
> directories.  Immediately after an embargoed release that included
> the change, 0f85c4a3 (setup: opt-out of check with safe.directory=*,
> 2022-04-13) was done as a response to loosen the check so that a
> single '*' can be used to say "I trust all repositories" for folks
> who host too many repositories to list individually.
> 
> Let's further allow people to say "everything under this hierarchy
> is deemed safe" by specifying such a leading directory with "/*"
> appended to it.

I welcome this change, too!

Acked-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

-K

Re: safe.directory wildcards

[Stefan Metzmacher]

Am 29.05.24 um 18:02 schrieb Junio C Hamano:
> Stefan Metzmacher <metze@samba.org> writes:
> 
>> given the recent importance of safe.directory, it would be great to
>> have something like '/data/git/*' to be supported, not just a single '*'
>> for a server that serves a lot of public git repositories owned by different owners.
> 
> Interesting.
> 
> The original commit that introduced the '*' opt-out, 0f85c4a3
> (setup: opt-out of check with safe.directory=*, 2022-04-13), was
> done to specifically help those who have a large list of shared
> repositories.  We could have moved all the way to allow globs back
> then, and the possibility certainly was brought up.
> 
>    https://lore.kernel.org/git/xmqqk0bt9bsb.fsf@gitster.g/
> 
> But the loosening was done in a context of "brown paper bag fix"
> so it is very much understandable that we did the simplest and most
> obvious thing to avoid making silly mistakes in a haste.

> I am reluctant to use wildmatch() but I would expect that in
> practice "leading path matches" (in other words, "everything under
> this directory is OK") is sufficient, perhaps?

That's exactly what I tried first and then looked
at the sources to check why it doesn't help :-)

I guess it will be useful to have.

Thanks!
metze

Re: safe.directory wildcards

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Wed, May 29, 2024 at 09:02:16AM -0700, Junio C Hamano wrote:
> Stefan Metzmacher <metze@samba.org> writes:
> 
> > given the recent importance of safe.directory, it would be great to
> > have something like '/data/git/*' to be supported, not just a single '*'
> > for a server that serves a lot of public git repositories owned by different owners.
> 
> Interesting.
> 
> The original commit that introduced the '*' opt-out, 0f85c4a3
> (setup: opt-out of check with safe.directory=*, 2022-04-13), was
> done to specifically help those who have a large list of shared
> repositories.  We could have moved all the way to allow globs back
> then, and the possibility certainly was brought up.
> 
>   https://lore.kernel.org/git/xmqqk0bt9bsb.fsf@gitster.g/
> 
> But the loosening was done in a context of "brown paper bag fix"
> so it is very much understandable that we did the simplest and most
> obvious thing to avoid making silly mistakes in a haste.
> 
> I am reluctant to use wildmatch() but I would expect that in
> practice "leading path matches" (in other words, "everything under
> this directory is OK") is sufficient, perhaps?

Is there any particular reason why you don't want to use wildmatch?
I'd think it to be a natural fit here, and it would provide a superset
of functionality provided by leading paths, only.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: safe.directory wildcards

[Chris Torek]

On Fri, May 31, 2024 at 1:18 AM Patrick Steinhardt <ps@pks.im> wrote:
> On Wed, May 29, 2024 at 09:02:16AM -0700, Junio C Hamano wrote:
> > I am reluctant to use wildmatch() but I would expect that in
> > practice "leading path matches" (in other words, "everything under
> > this directory is OK") is sufficient, perhaps?
>
> Is there any particular reason why you don't want to use wildmatch?
> I'd think it to be a natural fit here, and it would provide a superset
> of functionality provided by leading paths, only.

I have to agree with Patrick here that wildmatch would not be
surprising. If the concern is that it might be accidentally dangerous,
perhaps requiring one to set two knobs might suffice?

Of course I've also thought at many times that Mercurial's
"syntax: glob" and "syntax: whatever" rules were a good idea,
although not necessarily that particular notation. Perhaps
"safe.literal.directory" (aka safe.directory) and "safe.glob.directory"?

Chris

Re: safe.directory wildcards

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>> I am reluctant to use wildmatch() but I would expect that in
>> practice "leading path matches" (in other words, "everything under
>> this directory is OK") is sufficient, perhaps?
>
> Is there any particular reason why you don't want to use wildmatch?

Mostly out of the principle to avoid anything more complex than
absolutely necessary in a security relevant code path.

It is called "superstition" in other languages ;-).