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? -- 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