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
