Date: Sun, 28 Aug 2016 19:02:18 +0300 From: Dmitry Selyutin <ghostman.sd@...il.com> To: musl@...ts.openwall.com Subject: Re: readdir(3): behavior on descriptors with O_SEARCH Hi Rich, thank you for the detailed answer! > 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. Well, that's probably the worst kind of bugs, since it was caused by misinterpretation of the documentation. That was written intentionally due to misunderstanding, so I really want to clarify the situation here. So does it mean that descriptors opened with O_SEARCH are usable only for *at functions? I've been under the impression that it's part of the O_PATH functionality, not O_SEARCH. > 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. At the same time, if I understand you correctly, you mean that O_PATH is a different beast than O_SEARCH. I've found a mail in the DragonFly mailing list, which also slightly touches this topic. They also propose to use value 3 as currently unused value; I don't know if it is implemented yet. FWIW, neither OpenBSD nor FreeBSD provide O_SEARCH flag; the latter provides O_EXEC though. I finally have a good access to the Internet so I managed to find a detailed discussion on this topic. Sorry guys (and especially you, Rich) that I didn't find it before; it would have saved some questions earlier. Rich, could you please elaborate on the exact semantics of O_SEARCH flag? Again, thank you very much for your answer and for your patience!  https://www.dragonflybsd.org/mailarchive/kernel/2009-08/msg00000.html  https://sourceware.org/ml/libc-alpha/2013-08/msg00016.html 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.