Date: Sun, 28 Aug 2016 11:06:33 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: readdir(3): behavior on descriptors with O_SEARCH 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
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.