init --shared=0666 isn't

Steve Folly· Mar 9, 2010, 22:31 UTC · lore

Using git 1.7.0.2 on Mac OS X 10.6.2:

$ git init --bare --shared=0666 /tmp/shared.git
$ git --git-dir=/tmp/shared.git remote add --mirror \
        origin git://git.kernel.org/pub/scm/git/git.git
$ git --git-dir=/tmp/shared.git fetch origin

# login as someone else; different uid, different gid, then:

$ git --git-dir=/tmp/shared.git fetch origin

error: cannot open /tmp/shared.git/FETCH_HEAD: Permission denied

FETCH_HEAD is owned by the original user, with 0644 permissions,
 not 0666 as originally requested.

I've only had a quick glance at the source - my first guess
 is that in builtin-fetch.c, store_updated_refs and 
truncate_fetch_head should call adjust_shared_perm after
closing the file being written? Or, should an empty FETCH_HEAD
with appropriate shared perms be written during init?

In my case I'm using /tmp/shared.git as a mirror for other
 local repositories init'ed with --reference=/path/to/mirror.git
and all I'll be doing if fetching into it periodically, so I think fixing 
FETCH_HEAD will suffice for me.

But, I wonder if there are other files written that will need fixing also - ORIG_HEAD, MERGE_HEAD?

Is there a workaround for this or am I doing something wrong? Thanks for any help.

Regards, Steve

Junio C Hamano· Mar 9, 2010, 23:51 UTC · re: Steve Folly · lore

Re: init --shared=0666 isn't

Steve Folly <steve@spfweb.co.uk> writes:

Show 5 quoted lines

> $ git --git-dir=/tmp/shared.git fetch origin
>
> error: cannot open /tmp/shared.git/FETCH_HEAD: Permission denied
>
> FETCH_HEAD is owned by the original user, with 0644 permissions,

The shared repository support was [*1*] designed to help people setting up a "shared" repository like CVS/SVN, a central place people meet and exchange their histories by pushing into it and fetching from it. It was never designed to be used with a repository with a working tree, hence it was never designed to be used in repositories you would run "git pull" or "git merge" in.

However, it is not implausible for a sane workflow that you have to fetch into a central meeting place. You might be setting up a shared repository that also serves as a redistribution center for an external source, and in such a set-up, you would

 (1) clone/fetch from external "upstream";
 (2) allow people to fetch from it;
 (3) allow people to push into it.

So in that sense, allowing "git fetch" in such a shared central meeting place is not something we would want to actively forbid. But I thought we unlinked existing FETCH_HEAD and then opened to create it anew, so I am a bit puzzled why it matters who owns it and who can write into it.

    ... goes and looks ...

Ah, truncate_fetch_head() just opens it without unlinking. Probably a better fix might be to unlink and create the file, like the attached patch does, instead of running adjust_shared_perm().

> But, I wonder if there are other files written that will need fixing
> also - ORIG_HEAD, MERGE_HEAD?

These are created by "merge" and "reset", so it shouldn't matter.

By the way, the same applies to files in the working tree. We never call adjust_shared_perm() when creating them, and I do not think this is likely to change.

[Footnote]

*1* Notice the past tense---this is merely a statement of historical fact to help you understand _why_ the current system behaves that way and the conclusion does not necessarily have to be "hence it must remain that way".

diff --git a/builtin-fetch.c b/builtin-fetch.c
index b6c5b34..d73fa19 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -654,8 +654,11 @@ static void check_not_current_branch(struct ref *ref_map)
 static int truncate_fetch_head(void)
 {
 	char *filename = git_path("FETCH_HEAD");
-	FILE *fp = fopen(filename, "w");
+	FILE *fp;
 
+	if (unlink(filename) && errno != ENOENT)
+		return error("cannot unlink %s\n", filename);
+	fp = fopen(filename, "w");
 	if (!fp)
 		return error("cannot open %s: %s\n", filename, strerror(errno));
 	fclose(fp);