From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10401 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: readdir(3): behavior on descriptors with O_SEARCH Date: Sun, 28 Aug 2016 11:06:33 -0400 Message-ID: <20160828150633.GE15995@brightrain.aerifal.cx> References: <20160828071052.GA28382@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1472396814 17213 195.159.176.226 (28 Aug 2016 15:06:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 15:06:54 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10414-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 28 17:06:51 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1be1fd-0003rM-8k for gllmg-musl@m.gmane.org; Sun, 28 Aug 2016 17:06:49 +0200 Original-Received: (qmail 3830 invoked by uid 550); 28 Aug 2016 15:06:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3812 invoked from network); 28 Aug 2016 15:06:47 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10401 Archived-At: 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