Re: [PATCH] wrapper: Fix a errno discrepancy on NetBSD.

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Mon, May 05, 2025 at 08:43:18AM -0700, Junio C Hamano wrote:
>
>> But for other kind of requirements, we want to fulfill them on all
>> platforms that we claim to support.  Using open_nofollow() to
>> achieve hard atomicity requirement would be a bug in such a
>> situation.  Should we somehow warn our developers against its use?
>
> The comment above the declaration says:
>
>   /*
>    * Open with O_NOFOLLOW, or equivalent. Note that the fallback equivalent
>    * may be racy. Do not use this as protection against an attacker who can
>    * simultaneously create paths.
>    */
>   int open_nofollow(const char *path, int flags);
>
> though that may not be enough. 00611d8440 (add open_nofollow() helper,
> 2021-02-16) discusses a way that it could be made less racy, at a
> slightly increased cost.
>
> IMHO that is somewhat orthogonal to the issue here, though, which is
> purely about the case where O_NOFOLLOW does exist (ironically, our
> racy fallback code consistently returns ELOOP ;) ).

Yup.  And with the above comment, I would say that my worries above
are unfounded.

> The issue at hand is that particular errno responses are not always
> portable. The patch discussed here improves that. My point was more that
> I'm not sure to what degree we should care about errno consistency in
> our wrappers (which is inherently a bit whack-a-mole as we find new
> cases), versus trying not to care too hard about specific errno values
> in calling code.

Yeah, it does give me a bad aftertaste having to pretend (by adding
compat code to translate as needed) that all systems share the same
set of errno, but we live in not-so-ideal world, so I am afraild
that it cannot be avoided.

> I can see arguments either way (and as I said, an argument for making
> errno values consistent even if we try to rely on them less). Mostly I
> was just a little surprised to see open_nofollow() being used in this
> way (especially since we have to end up stat()-ing anyway to check for
> other cases).

That is true.

The callers in attr.c and dir.c do want to fstat() after they open,
but they are more interested in atomicity (with "the best effort on
less capable systems" attitude).  The one in mailmap.c doesn't do
any stat(), but again it is more about atomisity with the same
attitude, I think.