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,
next prev parent 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).