Re: Issue with insufficient permission for adding an object to repository database .git/objects

[Chris Torek <chris.torek@gmail.com>]

On Thu, Jul 16, 2020 at 7:30 AM LTPCGO | George <george@ltpcgo.com> wrote:
> I have attached a fix below, but it would be much better to fix in the
> code.  I am curious first, before proposing a fix in the code (although
> I can't find the specific call in the source at
> https://github.com/git/git ), what the reasoning is for the current
> permissions check on the call rather than checking the contents of the
> opened tmp file.

This is not in fact a bug in Git (which assumes POSIX semantics).
Git is not doing its own permissions checking here.  Rather, it is
a problem with the way the NFS software you are using attempts,
but fails, to emulate the POSIX requirements.

What Git does is this:

 * form the name of a file that we expect not to exist
 * use an open() system call in this way:

     fd = open(path, O_CREAT | O_EXCL | O_RDWR, 0444)

Note that this is a single, atomic system call that asks
the OS to:

 1. make sure the path does not exist currently -- if it
    does, return an error;
 2. create that path and open the resulting file for
    reading and writing, but make sure that no one else
    may write to that path.

On a local file system, this really is a single atomic
operation: either the path does not exist *and* you are
allowed to create it *and* the creation succeeds *and*
you now have a writable file-handle for a read-only file;
or, any one of the "and"s above has failed (file already
existed, you aren't allowed to create here, etc).

The underlying file is, in effect, write-once: *one* user
may write to the file, once, then close it.

Some NFS implementations, however, simply don't support this
operation as a single atomic operation.  In a best-effort attempt
to provide it anyway, they will do:

 1. test to see if the file exists, perhaps by doing an
    open with O_CREAT|O_EXCL themselves, but in an internal
    way that fails to obtain the file *handle*;
 2. chmod the underlying file to the desired mode;
 3. open the file again, this time to get a file handle.

In this case, the second open fails *because* the file is
set up to be "write-once": you cannot get a writable file
handle after the chmod.  But *Git* did not do the chmod.

Git could perhaps open these temporary files with mode
0644 instead of mode 0444, relying on the O_EXCL part and
self-coordination, then follow up later with an fchmod()
to set the mode to 0444.  But this opens a small window
for badly-behaved programs to obtain a file handle that
could be used to write to the Git object.

(Note that O_EXCL does not work well in general on NFS:
some systems do support it, but you're somewhat at the
mercy of your implementation.  See also
https://stackoverflow.com/questions/3406712/open-o-creat-o-excl-on-nfs-in-linux
and other reports you'll find by searching for "NFS O_EXCL"
on google.)

Chris