bug#75405: gzip --synchronous doesn't work with musl

[Lasse Collin]

On 2025-01-06 Paul Eggert wrote:
> On 2025-01-06 05:29, Lasse Collin wrote:
> > As far as I understand this, O_SEARCH in POSIX is only meant for
> > openat and such APIs.  
> 
> No, O_SEARCH is well defined in POSIX to work in plain 'open'. See 
> <https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html>.

I had looked at it a few times recently but somehow managed to convince
myself that "search only" means something else than it actually does.
Thanks for steering me back to the right path!

> > In musl, O_SEARCH maps to Linux-specific O_PATH  
> 
> That is a bug in musl. musl should not define O_SEARCH to O_PATH on 
> Linux, because O_PATH is not a valid implementation of O_SEARCH. Or
> if musl wants to do some sort of approximate-but-invalid
> implementation to POSIX, a better approximation is "#define O_SEARCH
> O_RDONLY", which is what Gnulib does in lib/fcntl.in.h. The
> approximation "#define O_SEARCH O_PATH" is more likely to break
> real-world applications than the approximation "#define O_SEARCH
> O_RDONLY" is.

musl's approach has the benefit that O_SEARCH works on dirs that lack
read permission but, now that I have researched it a bit more, I see it
indeed creates a bunch of new issues. For example, if a directory lacks
search permission, opening still succeeds. If one wants to use O_PATH
to create file descriptors for *at functions, one needs to write the
code slightly differently than when using O_SEARCH. So I agree that
O_RDONLY is a better approximation for O_SEARCH in the real world.

However, one thing that isn't an issue in musl is fchmod which is
currently documented in Gnulib's doc/posix-headers/fcntl.texi. fchmod
and a few others were fixed in 2013 by using /proc/self/fd.[1] Perhaps
Gnulib's docs could be updated to remove fchmod and add fsync and
fdatasync. Even if proc-based emulation was added, I don't see how it
could be great if it needs to do open+fsync+close where the open with
O_RDONLY might fail. But I might be missing something (again).

[1] 
https://git.musl-libc.org/cgit/musl/commit/?id=9ca1f62b0c0d3e50480eb654ac941ff943ce0558

> Would the following Gnulib patch work around the musl bug?

It does, thanks!

Should it check for __linux__ too to be sure that the workaround won't
accidentally apply on some other kernel or libc that has O_PATH? Or
perhaps it's safe to assume that nothing else has O_SEARCH == O_PATH.
For example, FreeBSD has O_PATH but, as expected, it doesn't equal
O_SEARCH.

It could be useful to add a test for gzip --synchronous. "make check"
passed without the Gnulib patch too.

-- 
Lasse Collin