git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael Lohmann <git@lohmann.sh>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/5] setup: refactor `ensure_safe_repository()` testing priorities
Date: Tue, 14 Oct 2025 13:32:09 -0700	[thread overview]
Message-ID: <xmqqy0pdw7g6.fsf@gitster.g> (raw)
In-Reply-To: <20251013094152.23597-4-git@lohmann.sh> (Michael Lohmann's message of "Mon, 13 Oct 2025 11:41:44 +0200")

Michael Lohmann <git@lohmann.sh> writes:

> The implicit ownership test takes precedence over the explicit
> allow-listing of a path by "safe.directory" config. Sort by "priority"
> (explicitness). This also allows to more easily integrate additional
> checks.
>
> Make the explicit safe.directory check take precedence over owner check.

I do not think the above argument makes much sense, with the code
with or without this patch.

It would be a very different story if the explicit specification
allowed users to configure a set of directories to be rejected, in
which case a user can mark a directory as unsafe even the
ownership-based rules would allow it, and explicit rules may have
higher "priority".

But that is not what safe_directory_cb() does.

In other words, there is no "priority" among the rules considered by
ensure_safe_repository() helper.  At least, with the shape of the
helper function at this step in the series, all rules are equally
capable of declaring a directory "safe".

If you are in later steps (I haven't read them) introducing ways to
say "this and that directories are explicitly forbidden", perhaps
reordering like this should be done at that point.

Alternatively, you can leave the change here in the middle of the
series, but explain the rationale differently, e.g.,

    With the current code, this change does not make any difference
    because there is no explicit rule that lets you reject a
    directory that the ownership-based rule may accept.  In a later
    step in this series, however, we will introduce a mechanism to
    allow such an explicit rule, at which point the order of checks,
    i.e. seeing the explicit rule reject a directory and failing the
    operation before consulting the ownership-based rule, will start
    to matter.  As a preliminary change, reorder the existing
    checks.

or something like that, perhaps.

> Signed-off-by: Michael Lohmann <git@lohmann.sh>
> ---
>  setup.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 69f6d1b36c..41a12a85ab 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1307,12 +1307,6 @@ static int ensure_safe_repository(const char *gitfile,
>  {
>  	struct safe_directory_data data = { 0 };
>  
> -	if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) &&
> -	    (!gitfile || is_path_owned_by_current_user(gitfile, report)) &&
> -	    (!worktree || is_path_owned_by_current_user(worktree, report)) &&
> -	    (!gitdir || is_path_owned_by_current_user(gitdir, report)))
> -		return 1;
> -
>  	/*
>  	 * normalize the data.path for comparison with normalized paths
>  	 * that come from the configuration file.  The path is unsafe
> @@ -1330,7 +1324,16 @@ static int ensure_safe_repository(const char *gitfile,
>  	git_protected_config(safe_directory_cb, &data);
>  
>  	free(data.path);
> -	return data.is_safe;
> +	if (data.is_safe)
> +		return 1;
> +
> +	if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) &&
> +	    (!gitfile || is_path_owned_by_current_user(gitfile, report)) &&
> +	    (!worktree || is_path_owned_by_current_user(worktree, report)) &&
> +	    (!gitdir || is_path_owned_by_current_user(gitdir, report)))
> +		return 1;
> +
> +	return 0;
>  }
>  
>  void die_upon_assumed_unsafe_repo(const char *gitfile, const char *worktree,

  reply	other threads:[~2025-10-14 20:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13  9:41 [PATCH 0/5] Allow enforcing safe.directory Michael Lohmann
2025-10-13  9:41 ` [PATCH 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-13  9:41 ` [PATCH 2/5] setup: rename `die_upon_assumed_unsafe_repo()` to align with check Michael Lohmann
2025-10-14 20:16   ` Junio C Hamano
2025-10-13  9:41 ` [PATCH 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-14 20:32   ` Junio C Hamano [this message]
2025-10-13  9:41 ` [PATCH 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-13  9:41 ` [PATCH 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-13 11:59   ` D. Ben Knoble
2025-10-13 21:46     ` [PATCH v2 0/5] Apply comments of D. Ben Knoble Michael Lohmann
2025-10-13 21:46       ` [PATCH v2 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-13 21:46       ` [PATCH v2 2/5] setup: rename `die_upon_assumed_unsafe_repo()` to align with check Michael Lohmann
2025-10-13 21:46       ` [PATCH v2 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-13 21:46       ` [PATCH v2 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-13 21:46       ` [PATCH v2 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-16  5:33 ` [PATCH v3 0/5] Allow skipping ownership of repo in safety consideration Michael Lohmann
2025-10-16  5:33   ` [PATCH v3 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-16  5:33   ` [PATCH v3 2/5] setup: rename `die_upon_unsafe_repo()` to align with check Michael Lohmann
2025-10-16  5:33   ` [PATCH v3 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-16  5:33   ` [PATCH v3 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-16 19:26     ` Junio C Hamano
2025-10-16  5:33   ` [PATCH v3 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-16 19:33     ` Junio C Hamano
2025-10-16 19:58     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy0pdw7g6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@lohmann.sh \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).