git init shared=group with a subdir

git init shared=group with a subdir

[petesea]

I believe there may be a bug when initializing a new repository relating 
to the directory permissions when the --shared=group option is used and 
the repository is within a sub-directory.

The following will create the "test.git" directory with 2775 permissions 
(which is as expected):

   $ ls -ld test.git
   ls: cannot access test.git: No such file or directory
   $ git init --bare --shared=group test.git
   Initialized empty shared Git repository in /tmp/test.git/
   $ ls -ld test.git
   drwxrwsr-x 7 pete users 4096 2012-11-14 11:15 test.git

This following will also create the "test.git" directory with 2775 
permissions, BUT the "subdir" directory ends up with 755 permissions:

   $ ls -ld subdir
   ls: cannot access subdir: No such file or directory
   $ git init --bare --shared=group subdir/test.git
   Initialized empty shared Git repository in /tmp/subdir/test.git/
   $ ls -ld subdir subdir/test.git
   drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir
   drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git

Assuming the "subdir" directory doesn't already exist and is created by 
the "git init" command AND the --shared=group option is used, then 
shouldn't the "subdir" directory also have 2775 permissions?

Re: git init shared=group with a subdir

[Junio C Hamano]

petesea@bigfoot.com writes:

>   $ ls -ld subdir
>   ls: cannot access subdir: No such file or directory
>   $ git init --bare --shared=group subdir/test.git
>   Initialized empty shared Git repository in /tmp/subdir/test.git/
>   $ ls -ld subdir subdir/test.git
>   drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir
>   drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git
>
> Assuming the "subdir" directory doesn't already exist and is created
> by the "git init" command AND the --shared=group option is used, then
> shouldn't the "subdir" directory also have 2775 permissions?

People who access this "test.git" does not need to be able to write
into subdir/foobar, so the lack of w bit for the group is perfectly
fine, no?  Depending on to whom you would want to expose things
other than "test.git" in "subdir", the desirable set of the
permission bits on "subdir" itself would be different, but the "git
init" command line does not give us enough information to infer what
exact mode is needed.

At least we should give r-x to the parent directories for the
classes of users to whom we give rwx to the repository itself.  In
your example, since we give rwx to user=pete and group=users on
"test.git", "subdir" should have r-x (or better) for user=pete and
group=users, so that result happens to be correct.

But I do not think we did the right thing by design but it turned
out to be correct by accident.  If your umask were 077 or something
tight, I suspect that we end up creating "subdir" with "rwx------",
and group members wouldn't be able to access "test.git".  We may
want to loosen it down to "rwxr-x---" in such a case, but doing so
unconditionally risks exposing things inside "subdir" other than
"test.git" to your group members, and worse yet, we would be doing
so without telling the user.  If your umask is set to a tight value,
it is likely that you did so on purpose, and it is debatable if it
is a good thing to do.  It is safer to create these leading
directories like "subdir" honoring the umask, give the user a chance
to make sure that other things in "subdir" can be exposed to people
who have access to "test.git", and let the user handle the
permission (perhaps running "chmod g+rx subdir" as necessary).  And
that is the behaviour you are observing, I think.