All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Adding hooks.directory config option; wiring into run_hook
@ 2011-12-16 18:00 Christopher Dale
  2011-12-16 18:06 ` Junio C Hamano
  2011-12-17  1:58 ` Aaron Schrab
  0 siblings, 2 replies; 6+ messages in thread
From: Christopher Dale @ 2011-12-16 18:00 UTC (permalink / raw)
  To: git

>From 92a34696bb4e76ae7a967666234f13d04858bb68 Mon Sep 17 00:00:00 2001
From: Christopher Dale <chrelad@gmail.com>
Date: Fri, 16 Dec 2011 10:55:26 -0600
Subject: [PATCH] Adding hooks.directory config option; wiring into run_hook

The new hooks.directory config option allows each git repository to
specify the location of the hooks for that repository. The default
remains $GIT_DIR/hooks. The ability to change the hooks directory is
necessary when stuck in an environment with enhanced security and
trusted path execution policies. These systems require that any file
that can be executed exhibit at least the following characteristics:

  * The executable, it's directory, and each directory above it are
    not writable.

Since the hooks directory is within a directory that by it's very nature
requires write permissions, hooks are a non-starter in git's current
state. This patch aims to allow a (most likely bare) repo to have it's
hooks directory customized to a location that meets the above
requirements.

I'm not terribly good at C++, so please let me know if I need to fix
anything. I saw that there were a bunch of scripts that have
GIT_DIR/hooks hard-coded in them. Since I'm not familiar with those
scripts, I will leave them alone for now. Maybe someone that is familiar
with the scripts can integrate the new configuration option into them?
---
 Documentation/config.txt               |    5 +++++
 contrib/completion/git-completion.bash |    1 +
 run-command.c                          |   25 +++++++++++++++++++++++--
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8a7d2d4..c23417c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1226,6 +1226,11 @@ help.autocorrect::
        value is 0 - the command will be just shown but not executed.
        This is the default.

+hooks.directory::
+       Override the default hook directory location GIT_DIR/hooks. This can be
+       usefull if you are in an environment that has trusted path execution for
+       example.
+
 http.proxy::
        Override the HTTP proxy, normally configured using the 'http_proxy'
        environment variable (see linkgit:curl[1]).  This can be overridden
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index cc1bdf9..066948e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2177,6 +2177,7 @@ _git_config ()
                help.autocorrect
                help.browser
                help.format
+               hooks.directory
                http.lowSpeedLimit
                http.lowSpeedTime
                http.maxRequests
diff --git a/run-command.c b/run-command.c
index 1c51043..2e5fa16 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "diff.h"
 #include "run-command.h"
 #include "exec_cmd.h"
 #include "argv-array.h"
@@ -65,6 +66,7 @@ static int execv_shell_cmd(const char **argv)
 #ifndef WIN32
 static int child_err = 2;
 static int child_notifier = -1;
+static const char *hook_directory = NULL;

 static void notify_parent(void)
 {
@@ -603,6 +605,14 @@ int finish_async(struct async *async)
 #endif
 }

+static int git_hook_config(const char *var, const char *value, void *cb)
+{
+       if (!strcmp(var, "hooks.directory"))
+               return git_config_pathname(&hook_directory, var, value);
+
+       return git_diff_ui_config(var, value, cb);
+}
+
 int run_hook(const char *index_file, const char *name, ...)
 {
        struct child_process hook;
@@ -612,11 +622,22 @@ int run_hook(const char *index_file, const char
*name, ...)
        va_list args;
        int ret;

-       if (access(git_path("hooks/%s", name), X_OK) < 0)
+       // If this is not reset to NULL, then strange stuff happens
+       hook_directory = NULL;
+
+       // Load the configuration for hooks.directory
+       git_config(git_hook_config, NULL);
+
+       // If the configuration is not set for hooks directory, set it to the
+       // default GIT_PATH/hooks directory that we all know and love.
+       if(hook_directory == NULL)
+               hook_directory = git_path("hooks");
+
+       if (access(mkpath("%s/%s", hook_directory, name), X_OK) < 0)
                return 0;

        va_start(args, name);
-       argv_array_push(&argv, git_path("hooks/%s", name));
+       argv_array_push(&argv, mkpath("%s/%s", hook_directory, name));
        while ((p = va_arg(args, const char *)))
                argv_array_push(&argv, p);
        va_end(args);
-- 
1.7.5.2.353.g5df3e

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] Adding hooks.directory config option; wiring into run_hook
  2011-12-16 18:00 [PATCH] Adding hooks.directory config option; wiring into run_hook Christopher Dale
@ 2011-12-16 18:06 ` Junio C Hamano
  2011-12-16 18:28   ` Christopher Dale
                     ` (2 more replies)
  2011-12-17  1:58 ` Aaron Schrab
  1 sibling, 3 replies; 6+ messages in thread
From: Junio C Hamano @ 2011-12-16 18:06 UTC (permalink / raw)
  To: Christopher Dale; +Cc: git

Christopher Dale <chrelad@gmail.com> writes:

> ...
> trusted path execution policies. These systems require that any file
> that can be executed exhibit at least the following characteristics:
>
>   * The executable, it's directory, and each directory above it are
>     not writable.
> 
> Since the hooks directory is within a directory that by it's very nature
> requires write permissions,...

Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
then you can point at any directory with hooks.directory and that would mean
it would defeat your "trusted path execution policies".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Adding hooks.directory config option; wiring into run_hook
  2011-12-16 18:06 ` Junio C Hamano
@ 2011-12-16 18:28   ` Christopher Dale
  2011-12-16 19:23   ` Junio C Hamano
  2011-12-17  3:03   ` Aaron Schrab
  2 siblings, 0 replies; 6+ messages in thread
From: Christopher Dale @ 2011-12-16 18:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Okidokee, thanks for your feedback :)

On Fri, Dec 16, 2011 at 12:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christopher Dale <chrelad@gmail.com> writes:
>
>> ...
>> trusted path execution policies. These systems require that any file
>> that can be executed exhibit at least the following characteristics:
>>
>>   * The executable, it's directory, and each directory above it are
>>     not writable.
>>
>> Since the hooks directory is within a directory that by it's very nature
>> requires write permissions,...
>
> Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
> then you can point at any directory with hooks.directory and that would mean
> it would defeat your "trusted path execution policies".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Adding hooks.directory config option; wiring into run_hook
  2011-12-16 18:06 ` Junio C Hamano
  2011-12-16 18:28   ` Christopher Dale
@ 2011-12-16 19:23   ` Junio C Hamano
  2011-12-17  3:03   ` Aaron Schrab
  2 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2011-12-16 19:23 UTC (permalink / raw)
  To: Christopher Dale; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> Christopher Dale <chrelad@gmail.com> writes:
>
>> ...
>> trusted path execution policies. These systems require that any file
>> that can be executed exhibit at least the following characteristics:
>>
>>   * The executable, it's directory, and each directory above it are
>>     not writable.
>> 
>> Since the hooks directory is within a directory that by it's very nature
>> requires write permissions,...
>
> Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
> then you can point at any directory with hooks.directory and that would mean
> it would defeat your "trusted path execution policies".

I was about to follow-up with "the only option that may make sense in such
an environment may be to disable hooks", but after thinking about it more,
if somebody enables hooks, the environment will make sure that they will
fail to execute, and it would be an incentive enough for people to disable
them. IOW, no need to have such an option, even.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re:  Adding hooks.directory config option; wiring into run_hook
  2011-12-16 18:00 [PATCH] Adding hooks.directory config option; wiring into run_hook Christopher Dale
  2011-12-16 18:06 ` Junio C Hamano
@ 2011-12-17  1:58 ` Aaron Schrab
  1 sibling, 0 replies; 6+ messages in thread
From: Aaron Schrab @ 2011-12-17  1:58 UTC (permalink / raw)
  To: Christopher Dale; +Cc: git

At 12:00 -0600 16 Dec 2011, Christopher Dale <chrelad@gmail.com> wrote:
>Since the hooks directory is within a directory that by it's very 
>nature requires write permissions,

Are you sure about this?  I'd think that this would mainly be used for 
bare repositories.  For a test I created a bare repository, removed 
write permission, changed the owner to root, then pushed into it from 
another repository.  So it seems that, at least for basic usage, a bare 
repository can be modified even if with write permission removed since 
no entries are being created or removed at the top level.

For this to be a workaround, new repositories would need to be created 
by an admin.  The requirement that the containing directory not be 
writeable wouldn't necessarily be an issue; at least on Linux I'm able 
to create files/directories as root even in a non-writeable directory.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re:  Adding hooks.directory config option; wiring into run_hook
  2011-12-16 18:06 ` Junio C Hamano
  2011-12-16 18:28   ` Christopher Dale
  2011-12-16 19:23   ` Junio C Hamano
@ 2011-12-17  3:03   ` Aaron Schrab
  2 siblings, 0 replies; 6+ messages in thread
From: Aaron Schrab @ 2011-12-17  3:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Christopher Dale, git

At 10:06 -0800 16 Dec 2011, Junio C Hamano <gitster@pobox.com> wrote:
>Christopher Dale <chrelad@gmail.com> writes:
>
>> ...
>> trusted path execution policies. These systems require that any file
>> that can be executed exhibit at least the following characteristics:
>>
>>   * The executable, it's directory, and each directory above it are
>>     not writable.
>>
>> Since the hooks directory is within a directory that by it's very nature
>> requires write permissions,...
>
>Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
>then you can point at any directory with hooks.directory and that would mean
>it would defeat your "trusted path execution policies".

How does that defeat the policy?  It would certainly allow somebody who 
can write to $GIT_DIR to disable hooks, use hooks that were meant for a 
different repository, or perhaps even use executables that weren't 
intended to be hooks.  If the proposed configuration option were 
modified by an attacker to point to some directory that doesn't meet the 
requirements, then the underlying system would still prevent execution; 
the same result that would happen if they'd try to install hooks in the 
traditional location.

I see other problems with that policy, at least with the short 
description that was provided.  Unless there are also restrictions on 
the allowed owners of the executable and its containing directories, an 
attacker would still be able to install new executables and then remove 
write permissions before trying to use them.  But, that flaw (if it 
exists) wouldn't be affected by the proposed change to git.

Requiring that all executables on a secured system be installed by an 
admin doesn't seem to be a completely unreasonable requirement.  The 
supplied patch looks to be fairly small and easy to understand, so I 
wouldn't think that including it would present much of a problem for 
maintaining git.

The option might also be useful to allow the same hooks directory to be 
used for multiple repositories, although symlinks would likely be a 
better way to do that.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-12-17  3:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-16 18:00 [PATCH] Adding hooks.directory config option; wiring into run_hook Christopher Dale
2011-12-16 18:06 ` Junio C Hamano
2011-12-16 18:28   ` Christopher Dale
2011-12-16 19:23   ` Junio C Hamano
2011-12-17  3:03   ` Aaron Schrab
2011-12-17  1:58 ` Aaron Schrab

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.