diff mbox series

[v5,2/4] git-compat-util: avoid failing dir ownership checks if running privileged

Message ID 20220513010020.55361-3-carenas@gmail.com (mailing list archive)
State Accepted
Commit ae9abbb63eea74441e3e8b153dc6ec1f94c373b4
Headers show
Series fix `sudo make install` regression in maint | expand

Commit Message

Carlo Marcelo Arenas Belón May 13, 2022, 1 a.m. UTC
bdc77d1d685 (Add a function to determine whether a path is owned by the
current user, 2022-03-02) 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.

Reported-by: Guy Maurel <guy.j@maurel.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Randall Becker <rsbecker@nexbridge.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/safe.txt  | 13 +++++++++
 git-compat-util.h              | 53 +++++++++++++++++++++++++++++++++-
 t/t0034-root-safe-directory.sh |  2 +-
 3 files changed, 66 insertions(+), 2 deletions(-)

Comments

SZEDER Gábor June 3, 2022, 11:05 a.m. UTC | #1
On Thu, May 12, 2022 at 06:00:18PM -0700, Carlo Marcelo Arenas Belón wrote:
> bdc77d1d685 (Add a function to determine whether a path is owned by the
> current user, 2022-03-02) 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.

Thanks for working on this!

Unfortunately, I haven't been able to follow the discussion on this
patch series at all, but by a cursory look now I didn't notice any
discussion about what should happen if someone were to use 'sudo' to
access a repository owned by root.  I think it should work, and it did
in fact work in the past, even after bdc77d1d685, but this patch
broke it.

Case in point are tools like 'etckeeper', which keeps track of '/etc'
in a root-owned Git repository, and hooks into package managers to
automatically create a commit when a package installation/update
changes something in '/etc'.  After this patch when 'sudo apt install
<pkg>' invokes 'etckeeper', it complains about the unsafe repository
in '/etc', and doesn't make that commit.


>  static inline int is_path_owned_by_current_uid(const char *path)
>  {
>  	struct stat st;
> +	uid_t euid;
> +
>  	if (lstat(path, &st))
>  		return 0;
> -	return st.st_uid == geteuid();
> +
> +	euid = geteuid();

Perhaps all we'd need is just a simple condition here:

        if (st.st_uid == euid)
                return 1;

which does make it work again in my manual tests, e.g.:

  $ id -u
  1000
  $ sudo ./git -C /etc/ rev-parse --absolute-git-dir
  /etc/.git

Alas, I couldn't get 't0034-root-safe-directory.sh' work for me at
all, so I'm not sure it doesn't break something else.

And it would also allow 'sudo -u somebody git ...' to access a
repository owned by that somebody, which, I think, should work as
well.

> +	if (euid == ROOT_UID)
> +		extract_id_from_env("SUDO_UID", &euid);
> +
> +	return st.st_uid == euid;
>  }
>  
>  #define is_path_owned_by_current_user is_path_owned_by_current_uid
Junio C Hamano June 3, 2022, 4:54 p.m. UTC | #2
SZEDER Gábor <szeder.dev@gmail.com> writes:

> Unfortunately, I haven't been able to follow the discussion on this
> patch series at all, but by a cursory look now I didn't notice any
> discussion about what should happen if someone were to use 'sudo' to
> access a repository owned by root.  I think it should work, and it did
> in fact work in the past, even after bdc77d1d685, but this patch
> broke it.

I thought 4/4 of the series was meant to discuss that?  Right now it
is split out as Carlo was hesitant to push the step forward?

https://lore.kernel.org/git/20220519152344.ktrifm3pc42bjruh@Carlos-MacBook-Pro-2.local/
SZEDER Gábor June 3, 2022, 5:34 p.m. UTC | #3
On Fri, Jun 03, 2022 at 09:54:34AM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
> 
> > Unfortunately, I haven't been able to follow the discussion on this
> > patch series at all, but by a cursory look now I didn't notice any
> > discussion about what should happen if someone were to use 'sudo' to
> > access a repository owned by root.  I think it should work, and it did
> > in fact work in the past, even after bdc77d1d685, but this patch
> > broke it.
> 
> I thought 4/4 of the series was meant to discuss that?  Right now it
> is split out as Carlo was hesitant to push the step forward?
> 
> https://lore.kernel.org/git/20220519152344.ktrifm3pc42bjruh@Carlos-MacBook-Pro-2.local/
> 

Oh, indeed.  I only looked through my mailbox, not the ML archives,
and I wasn't on Cc for the last two patches of the series.  Thanks for
pointing it out.

I think we do need that additional fix as well, because we now break
at least one tool built around Git.

Though looking at patch 4/4, I'm not so keen about restructuring the
extract_id_from_env() helper function into id_from_env_matches(),
because I'd prefer to have a helper function for ID extraction and
nothing else, and to have all the uid matching inside one function.
diff mbox series

Patch

diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt
index 6d764fe0ccf..c6ebd1674dd 100644
--- a/Documentation/config/safe.txt
+++ b/Documentation/config/safe.txt
@@ -26,3 +26,16 @@  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.
++
+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.
diff --git a/git-compat-util.h b/git-compat-util.h
index 63ba89dd31d..e7cbfa65c9a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -393,12 +393,63 @@  static inline int git_offset_1st_component(const char *path)
 #endif
 
 #ifndef is_path_owned_by_current_user
+
+#ifdef __TANDEM
+#define ROOT_UID 65535
+#else
+#define ROOT_UID 0
+#endif
+
+/*
+ * Do not use this function when
+ * (1) geteuid() did not say we are running as 'root', or
+ * (2) using this function will compromise the system.
+ *
+ * PORTABILITY WARNING:
+ * This code assumes uid_t is unsigned because that is what sudo does.
+ * If your uid_t type is signed and all your ids are positive then it
+ * should all work fine.
+ * If your version of sudo uses negative values for uid_t or it is
+ * buggy and return an overflowed value in SUDO_UID, then git might
+ * fail to grant access to your repository properly or even mistakenly
+ * grant access to someone else.
+ * In the unlikely scenario this happened to you, and that is how you
+ * got to this message, we would like to know about it; so sent us an
+ * email to git@vger.kernel.org indicating which platform you are
+ * using and which version of sudo, so we can improve this logic and
+ * maybe provide you with a patch that would prevent this issue again
+ * in the future.
+ */
+static inline void extract_id_from_env(const char *env, uid_t *id)
+{
+	const char *real_uid = getenv(env);
+
+	/* discard anything empty to avoid a more complex check below */
+	if (real_uid && *real_uid) {
+		char *endptr = NULL;
+		unsigned long env_id;
+
+		errno = 0;
+		/* silent overflow errors could trigger a bug here */
+		env_id = strtoul(real_uid, &endptr, 10);
+		if (!*endptr && !errno)
+			*id = env_id;
+	}
+}
+
 static inline int is_path_owned_by_current_uid(const char *path)
 {
 	struct stat st;
+	uid_t euid;
+
 	if (lstat(path, &st))
 		return 0;
-	return st.st_uid == geteuid();
+
+	euid = geteuid();
+	if (euid == ROOT_UID)
+		extract_id_from_env("SUDO_UID", &euid);
+
+	return st.st_uid == euid;
 }
 
 #define is_path_owned_by_current_user is_path_owned_by_current_uid
diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh
index f6a5d63ff41..6b8ea5357f6 100755
--- a/t/t0034-root-safe-directory.sh
+++ b/t/t0034-root-safe-directory.sh
@@ -28,7 +28,7 @@  test_expect_success SUDO 'setup' '
 	)
 '
 
-test_expect_failure SUDO 'sudo git status as original owner' '
+test_expect_success SUDO 'sudo git status as original owner' '
 	(
 		cd root/r &&
 		git status &&