Re: Adding hooks.directory config option; wiring into run_hook
- From
Aaron Schrab <aaron@schrab.com>
- Date
- Dec 17, 2011, 03:03 UTC
- Message-ID
- <20111217030327.GD30928@pug.qqx.org>
- In-Reply-To
- <7vmxasie6k.fsf@alter.siamese.dyndns.org>
At 10:06 -0800 16 Dec 2011, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
>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.