From bf7d977f8c9a01b4decab2ecbd1ba02203e5a8bc Mon Sep 17 00:00:00 2001 From: =?utf8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?= Date: Wed, 4 May 2016 22:58:10 +0000 Subject: [PATCH] githooks.txt: amend dangerous advice about 'update' hook ACL MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 build their own version of Git which doesn't run the 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 Signed-off-by: Junio C Hamano --- Documentation/githooks.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 0d94337a5..0dd618af8 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -274,9 +274,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 <> 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 -- 2.11.0