Re: [PATCH] Makefile: do not set setgid bit on directories on GNU/kFreeBSD

   * On some BSD systems, adding +s bit on directories is detrimental
     (it is not necessary on BSD to begin with). The installation
     procedure has been updated to take this into account.

I looked at the NetBSD 5 sources, and as expected files are created (unconditionally) with the gid of the parent directory.

Setting the setgid flag is only allowed if the inode's gid is in the process gid set. This is really about files that might be executed, but the check is independent of regular file/directory.

"git init --shared" creates a repository, mode 2775, and that normally seems fine. It seems good to have the sgid bit on, in case the repository is transferred to another machine with different semantics, and it's a clue to humans about the intended behavior, even if it's non-optional on BSD.

I created a directory, mode 755, owned by me, and with group that I *do not* belong to. Then, "git init --shared" produced:

  fatal: Could not make /home/gdt/FOO/.git/refs writable by group

but really the issue was setting the sgid bit:

# all with git version 1.7.6.3 13 $ l -d .git/refs/ drwxr-xr-x 2 gdt kmem 512 Oct 24 18:53 .git/refs/ 14 $ chmod g+w .git/refs/ 15 $ l -d .git/refs/ drwxrwxr-x 2 gdt kmem 512 Oct 24 18:53 .git/refs/ 16 $ chmod g+s .git/refs/ chmod: .git/refs/: Operation not permitted

However, this is a pathological situation, because I've created a shared repository that I can write to because I own it, and group kmem people can write to because they're in the group, but I couldn't write to other group kmem resources.

Is this not-allowed-to-set-setgid issue the problem the patch is trying to avoid? Or something else?

I did run the regression tests at one point and don't remember this failing.

So all in all I am agnostic as to whether DIR_HAS_BSD_GROUP_SEMANTICS should be defined on NetBSD; personally I prefer to see the setgid bits.