threads / patch / 37996

v3Don't make $GIT_DIR/config executable

Subject: [PATCH v3 0/1] Don't make $GIT_DIR/config executable

## tl;dr

3 messages between Nov 18, 2014 and Nov 18, 2014. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Michael Haggerty· Nov 18, 2014, 13:50 UTC · lore

Here is a new, svelte version of the patch to avoid setting the u+x bit on $GIT_DIR/config. Thanks to the many people who reviewed versions v1 [1] and v2 [2].

This time there is no attempt to fix the permissions in existing repositories; it only avoids creating new problems. It also includes a test, as suggested by Eric and sketched by Junio.

This version, like the previous versions, applies to maint. But (thanks to its new minimalist nature) this version can be merged to master without conflict.

Michael

[1] http://thread.gmane.org/gmane.comp.version-control.git/259620 [2] http://thread.gmane.org/gmane.comp.version-control.git/259644

Michael Haggerty (1):
  create_default_files(): don't set u+x bit on $GIT_DIR/config
 builtin/init-db.c | 3 ++-
 t/t0001-init.sh   | 7 +++++++
 2 files changed, 9 insertions(+), 1 deletion(-)
-- 
2.1.3
Michael Haggerty· Nov 18, 2014, 13:50 UTC · re: Michael Haggerty · lore

[PATCH v3 1/1] create_default_files(): don't set u+x bit on $GIT_DIR/config

Since time immemorial, the test of whether to set "core.filemode" has been done by trying to toggle the u+x bit on $GIT_DIR/config and then testing whether the change "took". I find it somewhat odd to use the config file for this test, but whatever.

The test code didn't set the u+x bit back to its original state itself, instead relying on the subsequent call to git_config_set() to re-write the config file with correct permissions.

But ever since
    daa22c6f8d config: preserve config file permissions on edits (2014-05-06)

git_config_set() copies the permissions from the old config file to the new one. This is a good change in and of itself, but it interacts badly with create_default_files()'s sloppiness, causing "git init" to leave the executable bit set on $GIT_DIR/config.

So change create_default_files() to reset the permissions on $GIT_DIR/config after its test.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 builtin/init-db.c | 3 ++-
 t/t0001-init.sh   | 7 +++++++
 2 files changed, 9 insertions(+), 1 deletion(-)
Show changes to 2 files +9 −1

builtin/init-db.c, t/t0001-init.sh

diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..a6d58fd 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -254,7 +254,8 @@ static int create_default_files(const char *template_path)
 		struct stat st2;
 		filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
 				!lstat(path, &st2) &&
-				st1.st_mode != st2.st_mode);
+				st1.st_mode != st2.st_mode &&
+				!chmod(path, st1.st_mode));
 	}
 	git_config_set("core.filemode", filemode ? "true" : "false");
 
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index e62c0ff..7de8d85 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -12,6 +12,13 @@ check_config () {
 		echo "expected a directory $1, a file $1/config and $1/refs"
 		return 1
 	fi
+
+	if test_have_prereq POSIXPERM && test -x "$1/config"
+	then
+		echo "$1/config is executable?"
+		return 1
+	fi
+
 	bare=$(cd "$1" && git config --bool core.bare)
 	worktree=$(cd "$1" && git config core.worktree) ||
 	worktree=unset
-- 
2.1.3
Stefan Beller· Nov 18, 2014, 17:17 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 1/1] create_default_files(): don't set u+x bit on $GIT_DIR/config

Reviewed-by: Stefan Beller <sbeller@google.com>
On Tue, Nov 18, 2014 at 5:50 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 66 quoted lines
> Since time immemorial, the test of whether to set "core.filemode" has
> been done by trying to toggle the u+x bit on $GIT_DIR/config and then
> testing whether the change "took". I find it somewhat odd to use the
> config file for this test, but whatever.
>
> The test code didn't set the u+x bit back to its original state
> itself, instead relying on the subsequent call to git_config_set() to
> re-write the config file with correct permissions.
>
> But ever since
>
>     daa22c6f8d config: preserve config file permissions on edits (2014-05-06)
>
> git_config_set() copies the permissions from the old config file to
> the new one. This is a good change in and of itself, but it interacts
> badly with create_default_files()'s sloppiness, causing "git init" to
> leave the executable bit set on $GIT_DIR/config.
>
> So change create_default_files() to reset the permissions on
> $GIT_DIR/config after its test.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  builtin/init-db.c | 3 ++-
>  t/t0001-init.sh   | 7 +++++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 56f85e2..a6d58fd 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -254,7 +254,8 @@ static int create_default_files(const char *template_path)
>                 struct stat st2;
>                 filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>                                 !lstat(path, &st2) &&
> -                               st1.st_mode != st2.st_mode);
> +                               st1.st_mode != st2.st_mode &&
> +                               !chmod(path, st1.st_mode));
>         }
>         git_config_set("core.filemode", filemode ? "true" : "false");
>
> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index e62c0ff..7de8d85 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -12,6 +12,13 @@ check_config () {
>                 echo "expected a directory $1, a file $1/config and $1/refs"
>                 return 1
>         fi
> +
> +       if test_have_prereq POSIXPERM && test -x "$1/config"
> +       then
> +               echo "$1/config is executable?"
> +               return 1
> +       fi
> +
>         bare=$(cd "$1" && git config --bool core.bare)
>         worktree=$(cd "$1" && git config core.worktree) ||
>         worktree=unset
> --
> 2.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

← back to recent threads