Hi Joakim, On 2015-09-21 19:08, Joakim Tjernlund wrote: > On Mon, 2015-09-21 at 09:48 -0700, Junio C Hamano wrote: >> Duy Nguyen <pclouds@xxxxxxxxx> writes: >> >> > Is it really necessary to remove write access in $GIT_DIR? Do we (git >> > devs) have some guidelines about things in $GIT_DIR? >> >> Those who are allowed to "git push" into it should be able to write >> there. It is a different matter that "git" program itself may make >> a policy decision to disallow some operations that the filesystem >> bits alone would have allowed (e.g. you can arrange the "pusher" to >> only come over the wire via "receive-pack" and "receive-pack" may >> deliberately lack support for writing into $GIT_DIR/config). >> > > I view $GIT_DIR similar to "/" and "/tmp". Normally one does not let > normal users write to "/" > as you want to keep this level clean. It is not obvious to everybody > what files are important > under $GIT_DIR when mixed with tmp files etc. > $GIT_DIR/tmp would solve this nicely. By now it is pretty clear that you won't find many people here you share your opinion about locking down the Git directory. The reason should be easy to understand: Git's concept is based on the idea that you have full control over your repository. Other repositories you might only have read access. But this idea you have, to somehow introduce fine-grained levels of control, this idea would imply that all of a sudden Git is no longer free to write to its files as it likes. And as far as Git is concerned, everything inside .git/ *are* its files. So in essence, the core concept of Git -- you clone a repository you cannot write to so that you have a local repository you can do *anything you like* to -- is pretty much incompatible with this idea of a selective lock down of files in .git/ that not only would require you to know very exactly what files Git might want to write, but also to keep yourself up-to-date with Git's development as to which files it might want to write for *every* new version. Making only .git/tmp/ a writable location further fails to acknowledge the fact that the hierarchy of to-be-written files follows the function of those files, not any write permission hierarchy. Since the idea seems so alien to Git's core concept, I called it "overzealous". If that hurt your feelings, I am sorry and would like to apologize. Having said all that, I believe that reiterating this idea without pointing to any benefit will continue to fail to convince people that the idea is sound and that Git's core concept should change. If you need to exert more control in a specific repository, you simply make it accessible only as a non-file-system remote (where only `git`, `git-receive-pack` and `git-upload-pack` are allowed to be executed) and define hooks that can accept or deny on a *much* finer level than file system permissions ever could, after all. Ciao, Johannes -- 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