On Thu, Jul 16, 2020 at 7:30 AM LTPCGO | George <george@xxxxxxxxxx> 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
