Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

[Joakim Tjernlund <joakim.tjernlund@transmode.se>]

On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote:
> 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@gmail.com> 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.

So I note.

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

Yes and some repos I only have partial write access to(config, hooks etc. might be readonly) 

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

This does not compute for me, files inside git are git's files, I only think that not all users
to a repo should have the same (write) access. In this case it mostly to protect the repo from "creative"
users and accidents.

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


Don't see how I can avoid some of that if you want to protect areas of the repo from accidents etc.

> 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


Curious, how would you set up some level of protection on a repo?

A .git/tmp/ would make housekeeping easier, you would know that every file under .git
should be there and if you find something you don't recognize you would react.

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

No feelings hurt, I too regret my choise of words.

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

Even if I did go through this hassle, I would prefer if temporary data were put somewhere else
than .git/ as I think mixing config/persistent data with temporary data in the same directory is something
that should be avoided.

Anyhow, I see that this idea is not something upstream agrees on so I will back off now.

  Jocke