Re: [PATCH v4 2/4] githooks.txt: Amend dangerous advice about 'update' hook ACL
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Any ACL you implement via an 'update' hook isn't actual access control
> if the user has login access to the machine running git, because they
> can trivially just built their own git version which doesn't run the
s/built their own git version/build their own version of git/;
Show 30 quoted lines
> hook.
>
> Change the documentation to take this dangerous edge case into account,
> and remove the mention of the advice originating on the mailing list,
> the users reading this don't care where the idea came up.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> Documentation/githooks.txt | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 7660b95..9051584 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -275,9 +275,11 @@ does not know the entire set of branches, so it would end up
> firing one e-mail per ref when used naively, though. The
> <<post-receive,'post-receive'>> hook is more suited to that.
>
> -Another use suggested on the mailing list is to use this hook to
> -implement access control which is finer grained than the one
> -based on filesystem group.
> +In an environment that restricts the users' access only to git
> +commands over the wire, this hook can be used to implement access
> +control without relying on filesystem ownership and group
> +membership. See linkgit:git-shell[1] for how you might use the login
> +shell to restrict the user's access to only git commands.
>
> Both standard output and standard error output are forwarded to
> 'git send-pack' on the other end, so you can simply `echo` messages