readdir(3): behavior on descriptors with O_SEARCH

[Dmitry Selyutin <ghostman.sd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

Hello everyone!

First of all, thank you for musl; it is an amazing tool and I really glad
I'm using it. I'm able to compile and run everything I write (of course if
POSIX standard applies).

Recently I've found some edge case where both musl-gcc and musl-clang
behave differently compared to usual gcc, clang and tcc, and I think the
reason lies in the musl library. The example code:

int const flags = (O_DIRECTORY | O_SEARCH);
int descriptor = open(path, flags);
DIR *handle = fdopendir(descriptor);
struct dirent *entry = readdir(handle);

To cut the long story short, any attempt to call readdir(3) on directory
handle obtained via fdopendir(3) returns NULL and sets the errno variable
to EBADF. This behavior arises only on descriptors opened with (O_DIRECTORY
| O_SEARCH) flags enabled; it goes away if O_SEARCH flag is removed.

So it seems that O_SEARCH is the reason; I thought that this flag tells
exactly "well, I'm going to use it for search only", which implies "well,
I'm going to use only readdir(3) to get information about files inside". Is
my interpretation correct?

I'm not really sure if it is a bug, since I suspect POSIX may allow open(3)
with (O_DIRECTORY | O_SEARCH) flags to behave in an implementation-defined
matter; it can be possible that file descriptors obtained via open(3) with
O_DIRECTORY flag set are guaranteed to work only with fchdir(3) and *at(3)
operations. However, if such behavior is intentional, it would be a good
idea (in my opinion) make fdopendir(3) return NULL (though it won't match
behavior e.g. for glibc).

I don't know if this behavior still matters since I doubt I use the latest
musl version; I couldn't find any relevant information about this behavior
though.

The musl version I'm using is 1.1.15; the code is compiled for x86_64. I'm
using the version provided by Arch repositories.

I don't have a stable Internet connection now, so I couldn't manage to take
a look at the corresponding code in musl; I'll do it as soon as possible
and create a patch if my assumptions are correct (and if the above behavior
still applies to musl).

Thank you for musl and patience (well, it was quite a long letter)!

[-- Attachment #2: Type: text/html, Size: 2444 bytes --]