From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10403 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Selyutin Newsgroups: gmane.linux.lib.musl.general Subject: Re: readdir(3): behavior on descriptors with O_SEARCH Date: Sun, 28 Aug 2016 19:02:18 +0300 Message-ID: References: <20160828071052.GA28382@voyager> <20160828150633.GE15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c18fb667545eb053b23e09b X-Trace: blaine.gmane.org 1472400180 31221 195.159.176.226 (28 Aug 2016 16:03:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 16:03:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10416-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 28 18:02:56 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 1be2Xs-0007Pn-Mh for gllmg-musl@m.gmane.org; Sun, 28 Aug 2016 18:02:52 +0200 Original-Received: (qmail 12108 invoked by uid 550); 28 Aug 2016 16:02:52 -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 12087 invoked from network); 28 Aug 2016 16:02:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=QmUpEBSLFLQ4BPqeM25Q7HuqPAiwlnB/R6ZBUjbqDV4=; b=EgOL/HkHj+/sWXeGyO+xLfk94xWAKZvWg/C/MNO+PGPkWGhUtF8MdWMOr7ASy89YNq dao0KcJ3W52+yX/me1s05C/YRXDNPoaCPugnpyotTuAYn7IyamH/X8kn1xmx0l6x9UjG rGNZarwbnwCUF6/RALcnR/WYUvHRPlqNh8uLEt9Hcx+Qd+wIZe8HRObV84+lQz3RZMKV 7k+hmkYdYflPyJvV8VT/ckl5nXwStZ4UDYNFepISdUmS6NkVr+5/3NSLOww+aXTWWBfc uoN6DXinbwtb/e/ot/ICJ6jFGVO0aXb+NhtqZS4eEPAEu6E05EAficjunEJZ7DIGjP6+ mzoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=QmUpEBSLFLQ4BPqeM25Q7HuqPAiwlnB/R6ZBUjbqDV4=; b=NWehOOiUfKHF95uRTtFsF1EqbdfGc4IMmiAOzcAasfDBy44rpmOHZW+M8zjwTy+6Kj DtA+Z5dbpoO9hnWZvmuIN66r05nUwr0IhOQzNwcjcZsZfCJQzDPxVKn22AabHV0sdU+k qQKCjR+IxFzcI3eWxu3opM7QW6iHHjEVbkxbP3bH3YFlkLAHV63ZL9utU2uxzMZAbQ5z J1Jd+wA6ru88JeDkS9Ji3MR+42PVXUdciY1B1u8ujoE6YFWqt4R9IlhXwZiL75GzeqWv cnCH2bC7mLEDCywIkDim9DQl/xNkQX2k5mnCfFJzJmXs5FbbHvzvTEQGva00YNOTbvMI xSdg== X-Gm-Message-State: AE9vXwMCaLDDU7sHtz7RNkyDPpUNugW+mP50yJ7Idl/iG9AE2FuZpUISE/BkTufouhB4XRzPTI9K3NUcZR4IXA== X-Received: by 10.176.83.15 with SMTP id x15mr7384226uax.68.1472400159227; Sun, 28 Aug 2016 09:02:39 -0700 (PDT) In-Reply-To: <20160828150633.GE15995@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10403 Archived-At: --94eb2c18fb667545eb053b23e09b Content-Type: text/plain; charset=UTF-8 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[0]. 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[1]. 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! [0] https://www.dragonflybsd.org/mailarchive/kernel/2009-08/msg00000.html [1] https://sourceware.org/ml/libc-alpha/2013-08/msg00016.html --94eb2c18fb667545eb053b23e09b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rich,

thank you for the detailed answ= er!

> If a program is doing this then trying to fdopend= ir/readdir, it's a
> bug in the program. A directory opened with = O_SEARCH is only usable
> for search (attempting to access a file/dir= ectory in that directory
> by name, using one of the *at functions) n= ot 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 wa= s written intentionally due to misunderstanding, so I really want to clarif= y the situation here.
So does it mean that descriptors opened= with O_SEARCH are usable only for *at functions?
I've be= en under the impression that it's part of the O_PATH functionality, not= O_SEARCH.

> It's been an ongoing fight even tryin= g 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 t= heir non-action) is going to be using
> O_PATH|3 for both of them. Th= is allows userspace open to process
> O_SEARCH and O_EXEC slightly di= fferently 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[= 0].
They also propose to use value 3 as currently unused valu= e; I don't know if it is implemented yet.
FWIW, neither O= penBSD nor FreeBSD provide O_SEARCH flag; the latter provides O_EXEC though= .

I finally have a good access to the Internet so I manag= ed to find a detailed discussion on this topic[1].
Sorry guys= (and especially you, Rich) that I didn't find it before; it would have= saved some questions earlier.

Rich, could you please ela= borate on the exact semantics of O_SEARCH flag?
Again, thank = you very much for your answer and for your patience!

--94eb2c18fb667545eb053b23e09b--