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.