Re: No fchmd. was: Re: [PATCH 00/14] Add submodule test harness
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:01:52
Torsten Bögershausen [off-list ref] writes:
On 2014-07-10 21.49, Junio C Hamano wrote: []quoted
If we limit the case to "Inherit permissions from the file we are replacing by taking a lock on it", which is the topic of discussion in this thread, we do not have to worry about how to configure the value (we do not have to) and adding a new parameter to tell the mode to hold-lock-file-for-update is unneeded (the function will have a pathname of the original and can learn the current permission bits itself).So something like this:
Yeah, I think something along those lines may be sufficient and we do not have to do anything when closing/committing, at least POSIX systems. I do not know if other filesystems we may care about let you open with 0400 and still write into it, though.
(I will probably not have the time to make a proper patch :-(
That's OK. I see many names on Cc: who are all capable of helping us ;-)
quoted hunk
diff --git a/lockfile.c b/lockfile.c index 4899270..134d5c8 100644 --- a/lockfile.c +++ b/lockfile.c@@ -156,6 +156,11 @@ static void resolve_symlink(struct strbuf *path) /* Make sure errno contains a meaningful value on error */ static int lock_file(struct lock_file *lk, const char *path, int flags) { + int perms = 0666; + struct stat st; + if (!lstat(path, &st)) + perms = st.st_mode & 0777; + if (!lock_file_list) { /* One-time initialization */ sigchain_push_common(remove_lock_file_on_signal);@@ -179,7 +184,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags) if (!(flags & LOCK_NODEREF)) resolve_symlink(&lk->filename); strbuf_addstr(&lk->filename, LOCK_SUFFIX); - lk->fd = open(lk->filename.buf, O_RDWR | O_CREAT | O_EXCL, 0666); + lk->fd = open(lk->filename.buf, O_RDWR | O_CREAT | O_EXCL, perms); if (lk->fd < 0) { strbuf_reset(&lk->filename); return -1;