# [PATCH v3 0/1] Don't make $GIT_DIR/config executable 3 messages from 2014-11-18 to 2014-11-18. Participants: Michael Haggerty, Stefan Beller. Thread: https://gitlist.dev/t/37996 ## Michael Haggerty, 2014-11-18 13:50 Subject: [PATCH v3 0/1] Don't make $GIT_DIR/config executable Message-ID: <1416318624-23048-1-git-send-email-mhagger@alum.mit.edu> URL: https://gitlist.dev/e/1416318624-23048-1-git-send-email-mhagger%40alum.mit.edu ``` 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, 2014-11-18 13:50 Subject: [PATCH v3 1/1] create_default_files(): don't set u+x bit on $GIT_DIR/config Message-ID: <1416318624-23048-2-git-send-email-mhagger@alum.mit.edu> URL: https://gitlist.dev/e/1416318624-23048-2-git-send-email-mhagger%40alum.mit.edu In-Reply-To: <1416318624-23048-1-git-send-email-mhagger@alum.mit.edu> ``` 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 --- 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 ``` ## Stefan Beller, 2014-11-18 17:17 Subject: Re: [PATCH v3 1/1] create_default_files(): don't set u+x bit on $GIT_DIR/config Message-ID: URL: https://gitlist.dev/e/CAGZ79kbTu5OGkJc4LUxKZ_4T4YpQwFB3%2B5b2iz8_f%3Dr6VJ6faA%40mail.gmail.com In-Reply-To: <1416318624-23048-2-git-send-email-mhagger@alum.mit.edu> ``` Reviewed-by: Stefan Beller On Tue, Nov 18, 2014 at 5:50 AM, Michael Haggerty wrote: > 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 > --- > 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 ```