Jeff King <peff@xxxxxxxx> writes: > The easiest way would be something like a "trust remote hooks" > environment variable, off by default. Admins in situation (2) could set > it for their git-daemon (or webserver, or whatever, or > gitolite-over-ssh), once they decided it was safe. Alice and Bob may work on the same project, and they may want to trust each other as participants of that project, but that does not mean Alice wants to give Bob a blanket access to places she owns that are not shared with the project members (e.g. her $HOME directory), so I am afraid "trust remote hooks" is not a workable solution for the casual sharing on sites that do not fall into either of your two classes. The real reason why the upload-hook violates the expectation of the users is because it would run as the user who fetches, I think. If it ran with the intersection of capabilities of the owner of the repository and the user who is fetching, I suspect that we would not have to worry about it. What would happen if we allowed some hooks to run only when the process is running under a group-id that can write into the repository? When Alice fetches from the repository, it would still run as her and would have an access to her $HOME, so this won't really work yet, but I am wondering if there is a workable alternative along this line. -- 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