From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10399 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 12:02:02 +0300 Message-ID: References: <20160828071052.GA28382@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c12371a5058a2053b1e0038 X-Trace: blaine.gmane.org 1472374946 16861 195.159.176.226 (28 Aug 2016 09:02:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 09:02:26 +0000 (UTC) Cc: musl@lists.openwall.com To: Dmitry Selyutin Original-X-From: musl-return-10412-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 28 11:02:23 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 1bdvyw-0003uk-Bt for gllmg-musl@m.gmane.org; Sun, 28 Aug 2016 11:02:22 +0200 Original-Received: (qmail 28176 invoked by uid 550); 28 Aug 2016 09:02:21 -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 28146 invoked from network); 28 Aug 2016 09:02:20 -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:cc; bh=G9u898W09qtWULq8r8EaP5hI4TnZDPrDJ9lDxhNM/9c=; b=jife3jt4XNO2skkRcjgaxKUYxO5jhVFarSHKaocikkzz7dtveVZVXLpNMVev3jGh43 nxfqSMdYlkl6WM9AvTJ7QkCOQZVQ4cw3NdVmsG1L1gk3nvru/EzOKaCADhPl2+BD5/nR bzyD0kIjMHQx5Qu1/oqlxiniO3WFZiBlm2FlwXiqVtYQqfMvIM0AWc3kXYPEa5yLemoD ckL887KZuhYO2dj32hNKNn9+T5DlnyE/JSw8NcVSQ/h/0EW5Mx2YeNr56+mcqtofoYjW V4L3fdpC9x/ucH8nyTfdgucGDmZfoPKchhnQbo02u7Kjih2mVCwn9SzKjqJhe8tldYWm 7vRw== 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:cc; bh=G9u898W09qtWULq8r8EaP5hI4TnZDPrDJ9lDxhNM/9c=; b=HRNjj2T2os5tb2Q8MrtMeSiS3Wlg5V1CeXArPaqSlVJVFDGWngrupHGkz7Icdp6WR2 m5LxPNYJvKP1jRcHj/Q1UfXUuObz0gqa/a64cWm5rpy1kCPXxW4Hz5zReBnVWpWZeZsI nAX09NJUlWo6hw+emmIsGkyDIYQoHMPrBYfDCUSLNYKjNrN/558TC5hGyZUkdWpkMOto +ZMqP2cOKy7MFExWB/L0cFMwMPP2kqVEdpa46JpfiigQim0D8FVKMCbUGLgO0Z0NZsFU pnG9btMmjUppKq0lNMOwPRnpE8S/CqaSh+Zj4HdHbZoeq5RopcWoTTJILw4+PP7vox9Y yXEA== X-Gm-Message-State: AE9vXwMgKsDTyvavCJpwGKSPOLTQVqs4cJvOiWU4DmWQTEahonbZD8JnWF+FiAxfXo5oxef8XSRfsISsiASy7w== X-Received: by 10.176.6.195 with SMTP id g61mr203657uag.92.1472374923874; Sun, 28 Aug 2016 02:02:03 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10399 Archived-At: --94eb2c12371a5058a2053b1e0038 Content-Type: text/plain; charset=UTF-8 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! --94eb2c12371a5058a2053b1e0038 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think the mistery is partially solved: glibc simply doesn&= #39;t have O_SEARCH, so the following code

#ifdef O_SEARCH
flags |=3D O_SEARCH
#endif

does not execute (so only O_DIRECTORY is being set). Dumb, h= ad 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 sam= e value as O_PATH, but I'm not sure if this solution is technically cor= rect.

However, I suspect that support for O_EXEC and O_SEARCH must= be provided by the kernel first, so until kernel implements such functiona= lity, all talks seem to be meaningless (unless someone wants to emulate suc= h 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; w= hat do you think? The information on O_SEARCH seems to be incomplete and ev= en inconsistent, so it may turn that my claims are incorrect. Any suggestio= ns are welcome; I'll take a more deep look at it in the evening.

And again, thank you for your help!

--94eb2c12371a5058a2053b1e0038--