Christopher Dale [off-list ref] 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".
Okidokee, thanks for your feedback :)
On Fri, Dec 16, 2011 at 12:06 PM, Junio C Hamano [off-list ref] wrote:
Christopher Dale [off-list ref] writes:
quoted
...
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".
At 10:06 -0800 16 Dec 2011, Junio C Hamano [off-list ref] wrote:
Christopher Dale [off-list ref] writes:
quoted
...
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.