Jeff King <p...@peff.net> writes: > Probably converting "rename(from, to)" to first check "access(to, > W_OK)". That's racy, but it's the best we could do.
Hmph, if these (possibly problematic) callers are all following the usual "lock, write to temp, rename" pattern, perhaps the lock_file() function can have access(path, W_OK) check before it returns a tempfile that has been successfully opened? Having said that, I share your assessment that this is not a code or design problem. It is unreasonable to drop the write-enable bit of a file in a writable directory and expect it to stay unmodified. The W-bit on the file is not usable as a security measure, and we do not use it as such. I do not offhand know how much a new feature "this repository can be modified by pushing into and fetching from, but its configuration cannot be modified" is a sensible thing to have. But it is quite clear that even if we were to implement such feature, we wouldn't be using W-bit on .git/config to signal that.
