Skip to content

Commit bf7d977

Browse files
avargitster
authored andcommitted
githooks.txt: amend dangerous advice about 'update' hook ACL
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 <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 49fa52f commit bf7d977

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed

Documentation/githooks.txt

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -274,9 +274,11 @@ does not know the entire set of branches, so it would end up
274274
firing one e-mail per ref when used naively, though. The
275275
<<post-receive,'post-receive'>> hook is more suited to that.
276276

277-
Another use suggested on the mailing list is to use this hook to
278-
implement access control which is finer grained than the one
279-
based on filesystem group.
277+
In an environment that restricts the users' access only to git
278+
commands over the wire, this hook can be used to implement access
279+
control without relying on filesystem ownership and group
280+
membership. See linkgit:git-shell[1] for how you might use the login
281+
shell to restrict the user's access to only git commands.
280282

281283
Both standard output and standard error output are forwarded to
282284
'git send-pack' on the other end, so you can simply `echo` messages

0 commit comments

Comments
 (0)