[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