* 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.
Attachment:
pgpxBtM1VvJcE.pgp
Description: PGP signature