[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Aug 2016 12:02:02 +0300
From: Dmitry Selyutin <ghostman.sd@...il.com>
To: Dmitry Selyutin <ghostmansd@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: readdir(3): behavior on descriptors with O_SEARCH
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
does not execute (so only O_DIRECTORY is being set). Dumb, had to check
twice, sorry for the noise.
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.
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.
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.
And again, thank you for your help!
Content of type "text/html" skipped
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.
