Re: readdir(3): behavior on descriptors with O_SEARCH

[Rich Felker <dalias@libc.org>]

On Sun, Aug 28, 2016 at 12:02:02PM +0300, Dmitry Selyutin wrote:
> I think the mistery is partially solved: glibc simply doesn't have
> O_SEARCH, so the following code
> 
> #ifdef O_SEARCH
> flags |= O_SEARCH
> #endif

If a program is doing this then trying to fdopendir/readdir, it's a
bug in the program. A directory opened with O_SEARCH is only usable
for search (attempting to access a file/directory in that directory
by name, using one of the *at functions) not for reading. Unix has
always distinguished search (+x) and read (+r) permission for
directories and O_SEARCH vs O_RDONLY is similar.

> However, the question if it is correct to define O_SEARCH to be equal to
> O_PATH. From what I see, both O_SEARCH and O_EXEC have the same value as
> O_PATH, but I'm not sure if this solution is technically correct.

It's not quite, but there are only a few minor technical differences,
and most of them can be papered over from userspace. We're not doing
all that yet. The only one I'm aware of that needs kernel help is
allowing search even if the user has lost permission (chmod -x)
between the time the directory was opened successfully for O_SEARCH
and the time of the *at function.

> However, I suspect that support for O_EXEC and O_SEARCH must be provided by
> the kernel first, so until kernel implements such functionality, all talks
> seem to be meaningless (unless someone wants to emulate such functionality
> in the userspace). Anyway, I tend to think that any attempt to use O_SEARCH
> until then should either return -1 on open(3), or NULL on fdopendir(3); I
> really don't think that O_SEARCH shall mean the same as O_PATH.

It's been an ongoing fight even trying to get the kernel to reserve a
bit number for them. It looks like the correct course of action (the
one that's compatible with their non-action) is going to be using
O_PATH|3 for both of them. This allows userspace open to process
O_SEARCH and O_EXEC slightly differently from O_PATH (O_NOFOLLOW has
different semantics) and the kernel will ignore the extra access mode
bits with O_PATH anyway.

> But I'm by no means claim myself to be a POSIX expert; what do you think?
> The information on O_SEARCH seems to be incomplete and even inconsistent,
> so it may turn that my claims are incorrect. Any suggestions are welcome;
> I'll take a more deep look at it in the evening.

I don't see what's incomplete or inconsistent about it.

Rich