On Mon, Aug 07 2017, René Scharfe jotted:
> Am 07.08.2017 um 03:18 schrieb brian m. carlson:
>> On Sun, Aug 06, 2017 at 11:38:50PM +0000, Ævar Arnfjörð Bjarmason wrote:
>>> Change an argument to test_line_count (which'll ultimately be turned
>>> into a "test" expression) to use "-gt" instead of ">" for an
>>> arithmetic test.
>>>
>>> This broken on e.g. OpenBSD as of v2.13.0 with my commit
>>> ac3f5a3468 ("ref-filter: add --no-contains option to
>>> tag/branch/for-each-ref", 2017-03-24).
>>>
>>> Upstream just worked around it by patching git and didn't tell us
>>> about it, I discovered this when reading various Git packaging
>>> implementations: https://github.com/openbsd/ports/commit/7e48bf88a20
>>>
>>> Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com>
>>> ---
>>>
>>> David, it would be great to get a quick bug report to
>>> git@vger.kernel.org if you end up having to monkeypatch something
>>> we've done. We won't bite, promise :)
>>>
>>> As shown in that linked Github commit OpenBSD has another recent
>>> workaround in turning on DIR_HAS_BSD_GROUP_SEMANTICS and skipping a
>>> related test, maybe René can make more sense of that?
>>
>> I've confirmed using the NetBSD 7.1 man pages that NetBSD will also want
>> DIR_HAS_BSD_GROUP_SEMANTICS. MirBSD will also, according to its man
>> pages.
>>
>> As I understand it, the only consequence of not setting this flag on BSD
>> systems is that some directories will be setgid, which, while ugly and
>> useless, should have no negative effect.
>
> Right; specifically it's for newly created subdirectories of shared
> directories, which we want to be owned by the same group as their
> parent. That's the default on BSDs, and we have to set the setgid bit to
> turn on that semantic only on other systems, e.g. on Linux.
>
> 81a24b52c1 (Do not use GUID on dir in git init --shared=all on FreeBSD)
> introduced DIR_HAS_BSD_GROUP_SEMANTICS with the rationale that setting
> setgid on directories may not even be allowed for normal users. I can't
> reproduce this (t1301 succeeds for me on FreeBSD 10.3 even without that
> build flag), but apparently at least in some configurations it's not just
> a cosmetic issue.
>
> The skipped test 'init in long base path' in t0001 is a different kettle
> of fish. getcwd(3) on OpenBSD respects permissions on the parent
> directories up to root. E.g. after "chmod 711 /home" normal users would
> get EACCES when they'd call getcwd(3) in their homes there, while e.g.
> on Linux and FreeBSD they'd successfully get their current working dir.
Good summary. As openbsd-tech points out it seems the bug is ours, if
I'm understanding this correctly:
http://marc.info/?l=openbsd-tech&m=149625768825173&w=2
[EACCES]
Search permission was denied for the current directory, or read or
search permission was denied for a directory above the current
directory in the file hierarchy.
