[Bug] Permissions of temp file created in git's sha1_file.c correct?

Hello,

I recently (very recently: yesterday) started using git. I switched from
Bazaar, that required me to have a file system that supports the executable
flag (as it always stores this flag based on what the file system says).
FAT does not support the executable flag.

To make a long story short: I modified Apple's FAT kernel extension to
support both, executable and the writable flag. With this file system, I
was not able to push a change to the repository that is stored on a volume
using the file system. I tracked the problem down to one changeset:
<http://git.kernel.org/?p=git/git.git;a=commit;h=5256b006312e4d06e11b49a8b128e9e550e54f31>
introduces the line "fd = git_mkstemp_mode(buffer, 0444);" in sha1_file.c.

This line creates a temporary file that has reading rights for everyone but
no writing rights. I was astonished that it is possible to actually write
to a file you do not have write permission on. My file system driver does
not allow any change on read-only files except changing rights. Especially
it refuses to rename or delete the file. Both is tried some lines after the
file creation (move_temp_to_file, called when returning from
write_loose_object), resulting in an error that aborts the push.

I think that my file system is right (of course ;-) ): A file that is not
writable must not be renamed (arguable as the name could be seen as the
content of the containing directory) and it must not be deleted.

Do anyone agree? If so, my suggestion is to replace both occurrences of
"0444" in sha1_file.c by "0644" (or better
"S_IRUSR|S_IWUSR|S_IWGRP|S_IWOTH", or even "0600"/"S_IRUSR|S_IWUSR"). The
changed rights are changed at the end of move_temp_to_file anyways and
allowing the owner to write to the file is probably not a security issue.

Bye,
   Daniel