On Mon, Apr 25, 2016 at 8:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jacob Keller <jacob.keller@xxxxxxxxx> writes: > >>> -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. >>> +Another use for this hook to implement access control which is finer >>> +grained than the one based on filesystem group. Note that if the user >>> +pushing has a normal login shell on the machine receiving the push >>> +implementing access control like this can be trivially bypassed by >>> +just using not executing the hook. In those cases consider using >> >> "by just using not executing the hook." >> >> This grammar doesn't make sense. It doesn't quite match what you said >> in the commit message either. >> >>> +e.g. linkgit:git-shell[1] as the login shell to restrict the user's >>> +access. > > While there is nothing technically wrong in what it says, I wonder > if it is worth to state the obvious. If one can bypass update hook, > one can bypass any other hook, so the information does not even > belong here. > > Instead of saying "acl can be implemented on top of update hook, but > not quite because you can bypass it", it may be more useful to say > "in an environment that restricts the users' access only to git > commands over the wire, this hook can be used to access control > without relying on filesystem ownership and group membership", > perhaps? Will fix to use something closer to that phrasing. -- 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