Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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/; > 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@xxxxxxxxx> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html