[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160828071052.GA28382@voyager>
Date: Sun, 28 Aug 2016 09:10:52 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: readdir(3): behavior on descriptors with O_SEARCH
On Sat, Aug 27, 2016 at 09:23:50PM +0300, Dmitry Selyutin wrote:
> 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.
>
Try strace(1). That should tell you what glibc and musl are doing
differently. For instace, whether glibc removes O_SEARCH from the fd.
musl defines O_SEARCH to be equal to O_PATH. The manpage says that
O_PATH means the file isn't opened for reading. I guess if you do that
then getdents(2) will fail, which is what musl uses to implement
readdir(3).
I tried to do the same trace in glibc 2.19 (which is what Debian stable
is using right now), but to no avail: O_SEARCH isn't even mentioned
anywhere in that code. But its implementation of fdopendir(3) rejects
fds open only for writing. The readdir(3) implementation is, of course,
overcomplicated, but also seems to just call getdents(2). And then it
tries to pack the kernel structures into its own structures, probably
for ABI reasons. And people wonder why I dislike dynamic linking...
> 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?
>
My manpage doesn't know O_SEARCH, but it knows O_PATH, and then you're
wrong. It means "I'll only use this fd in *at() and fchdir() and
similar; this fd isn't open for reading."
> 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).
>
POSIX doesn't know O_SEARCH or O_PATH, and thus mandates nothing about
their meaning.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
