From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10398 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 11:12:54 +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=94eb2c18fb6689199d053b1d50fa X-Trace: blaine.gmane.org 1472371996 18815 195.159.176.226 (28 Aug 2016 08:13:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 08:13:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10411-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 28 10:13:10 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 1bdvDI-0004Ey-D6 for gllmg-musl@m.gmane.org; Sun, 28 Aug 2016 10:13:08 +0200 Original-Received: (qmail 18282 invoked by uid 550); 28 Aug 2016 08:13:07 -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 18258 invoked from network); 28 Aug 2016 08:13:06 -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=p67ZHCLM8Zfsl/jFUBMtgRoCJfwuHhObOzYRC6iOjws=; b=JcwDRfs0hcX/OjweTq7ZkEvvqiijWjQPs3Z/EZcz1lt5zTnVXosDH9C4XSY7GBqvvO U2U/RtfbDFVhxAryaiAeK6dGR4qtVSbR7Sj8xF5cUkxnOl/25gxFVNONpRHa7x1SmB2a kiBX2KEO4rwFTda9tI+e40hTVmUEvX4fQ7yIjDeBOxmKcPNzrczs9aenCWNJd4WdNa2E 017k46U120A121uOvMA13ra3VCIO01XucasKvJwUz94WEOu5ug7WCXSo2NyUMEjGvN2h qL75ZZgCVgIpCdOpnXVlwOGWc8E0jxvwT7OSx1gFfNwkqgtJBstb/ac9kJOmqT3Kulci T5JQ== 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=p67ZHCLM8Zfsl/jFUBMtgRoCJfwuHhObOzYRC6iOjws=; b=SlV3gt8isolxaBQrVwpwB+0OWdbTHaPjQoXFmFsKTHJSez4IHG+OOER1tqonNLAU5y X6hzrY8bsx8pDOeS7wiT6c2izhWYyQZbjgTvRRy2K5Tle79lB7Quhr6CzdHgpXsS0w1R WrC/lzVWtGLVJjGKLyBpo04RJWEgDHnwHnjmIS+NTGDcEGUUN97h1EGCC150/BgsNMM8 Rm6MCjdR1QnzYroAnHNseao1EVNKSMeqZHlYUfFv9l63mjEC4nzHRlMakm4XC6Huz9W/ ePEu9kF3HIdTn1h2whpxd7CQNAhOXyYZI76EMEZJMIhKst/+af+QcFt6oN2frCa6xnkp mYnQ== X-Gm-Message-State: AE9vXwOJM2nZUvRvoh3EimxC5iN+hIsWUgMqys+19QyC+CNBYdlZun9Jz2Ax0vbWWBvd7YuckocStWeQKxzWuQ== X-Received: by 10.176.83.15 with SMTP id x15mr6727965uax.68.1472371974803; Sun, 28 Aug 2016 01:12:54 -0700 (PDT) In-Reply-To: <20160828071052.GA28382@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:10398 Archived-At: --94eb2c18fb6689199d053b1d50fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Markus, thank you for your reply! > POSIX doesn't know O_SEARCH or O_PATH, and thus mandates nothing about > their meaning. POSIX 2008 with 2013 corrigenda mentions both O_SEARCH and O_EXEC. http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html > Try strace(1). That should tell you what glibc and musl are doing > differently. For instace, whether glibc removes O_SEARCH from the fd. Thank you! I'll try it and report the results here. FWIW it does not seem to be correct that O_SEARCH can be equal to O_PATH; from what I gathered from manuals and various mailing lists discussions, O_SEARCH may be equal to O_EXEC since each of these flags is valid either for directory or file respectively. 28 =D0=B0=D0=B2=D0=B3. 2016 =D0=B3. 10:11 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0= =BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Markus Wichmann" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > On Sat, Aug 27, 2016 at 09:23:50PM +0300, Dmitry Selyutin wrote: > > int const flags =3D (O_DIRECTORY | O_SEARCH); > > int descriptor =3D open(path, flags); > > DIR *handle =3D fdopendir(descriptor); > > struct dirent *entry =3D readdir(handle); > > > > To cut the long story short, any attempt to call readdir(3) on director= y > > handle obtained via fdopendir(3) returns NULL and sets the errno variab= le > > to EBADF. This behavior arises only on descriptors opened with > (O_DIRECTORY > > | O_SEARCH) flags enabled; it goes away if O_SEARCH flag is removed. > > > > Try strace(1). That should tell you what glibc and musl are doing > differently. For instace, whether glibc removes O_SEARCH from the fd. > > musl defines O_SEARCH to be equal to O_PATH. The manpage says that > O_PATH means the file isn't opened for reading. I guess if you do that > then getdents(2) will fail, which is what musl uses to implement > readdir(3). > > I tried to do the same trace in glibc 2.19 (which is what Debian stable > is using right now), but to no avail: O_SEARCH isn't even mentioned > anywhere in that code. But its implementation of fdopendir(3) rejects > fds open only for writing. The readdir(3) implementation is, of course, > overcomplicated, but also seems to just call getdents(2). And then it > tries to pack the kernel structures into its own structures, probably > for ABI reasons. And people wonder why I dislike dynamic linking... > > > So it seems that O_SEARCH is the reason; I thought that this flag tells > > exactly "well, I'm going to use it for search only", which implies "wel= l, > > I'm going to use only readdir(3) to get information about files inside"= . > Is > > my interpretation correct? > > > > My manpage doesn't know O_SEARCH, but it knows O_PATH, and then you're > wrong. It means "I'll only use this fd in *at() and fchdir() and > similar; this fd isn't open for reading." > > > I'm not really sure if it is a bug, since I suspect POSIX may allow > open(3) > > with (O_DIRECTORY | O_SEARCH) flags to behave in an > implementation-defined > > matter; it can be possible that file descriptors obtained via open(3) > with > > O_DIRECTORY flag set are guaranteed to work only with fchdir(3) and > *at(3) > > operations. However, if such behavior is intentional, it would be a goo= d > > idea (in my opinion) make fdopendir(3) return NULL (though it won't mat= ch > > behavior e.g. for glibc). > > > > POSIX doesn't know O_SEARCH or O_PATH, and thus mandates nothing about > their meaning. > > Ciao, > Markus > --94eb2c18fb6689199d053b1d50fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Markus,

thank you for your reply!

> POSIX doesn't know O_SEARCH or O_PATH, and thus man= dates nothing about
> their meaning.
POSIX 2008 with 2013 corrigenda mentions both O_SEARCH and O_EXEC.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

> Try strace(1). That should tell you what glibc and musl= are doing
> differently. For instace, whether glibc removes O_SEARCH from the fd.<= br> Thank you! I'll try it and report the results here.

FWIW it does not seem to be correct that O_SEARCH can be equ= al to O_PATH; from what I gathered from manuals and various mailing lists d= iscussions, O_SEARCH may be equal to O_EXEC since each of these flags is va= lid either for directory or file respectively.

28 =D0=B0=D0=B2=D0=B3. 2016 =D0=B3. 10:11 =D0=BF= =D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Ma= rkus Wichmann" <nullplan@gmx.ne= t> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
On Sat, Aug 27, 2016 at 09:23:50PM +0300,= Dmitry Selyutin wrote:
> int const flags =3D (O_DIRECTORY | O_SEARCH);
> int descriptor =3D open(path, flags);
> DIR *handle =3D fdopendir(descriptor);
> struct dirent *entry =3D readdir(handle);
>
> To cut the long story short, any attempt to call readdir(3) on directo= ry
> handle obtained via fdopendir(3) returns NULL and sets the errno varia= ble
> to EBADF. This behavior arises only on descriptors opened with (O_DIRE= CTORY
> | O_SEARCH) flags enabled; it goes away if O_SEARCH flag is removed. >

Try strace(1). That should tell you what glibc and musl are doing
differently. For instace, whether glibc removes O_SEARCH from the fd.

musl defines O_SEARCH to be equal to O_PATH. The manpage says that
O_PATH means the file isn't opened for reading. I guess if you do that<= br> then getdents(2) will fail, which is what musl uses to implement
readdir(3).

I tried to do the same trace in glibc 2.19 (which is what Debian stable
is using right now), but to no avail: O_SEARCH isn't even mentioned
anywhere in that code. But its implementation of fdopendir(3) rejects
fds open only for writing. The readdir(3) implementation is, of course,
overcomplicated, but also seems to just call getdents(2). And then it
tries to pack the kernel structures into its own structures, probably
for ABI reasons. And people wonder why I dislike dynamic linking...

> So it seems that O_SEARCH is the reason; I thought that this flag tell= s
> exactly "well, I'm going to use it for search only", whi= ch implies "well,
> I'm going to use only readdir(3) to get information about files in= side". Is
> my interpretation correct?
>

My manpage doesn't know O_SEARCH, but it knows O_PATH, and then you'= ;re
wrong. It means "I'll only use this fd in *at() and fchdir() and similar; this fd isn't open for reading."

> I'm not really sure if it is a bug, since I suspect POSIX may allo= w open(3)
> with (O_DIRECTORY | O_SEARCH) flags to behave in an implementation-def= ined
> matter; it can be possible that file descriptors obtained via open(3) = with
> O_DIRECTORY flag set are guaranteed to work only with fchdir(3) and *a= t(3)
> operations. However, if such behavior is intentional, it would be a go= od
> idea (in my opinion) make fdopendir(3) return NULL (though it won'= t match
> behavior e.g. for glibc).
>

POSIX doesn't know O_SEARCH or O_PATH, and thus mandates nothing about<= br> their meaning.

Ciao,
Markus
--94eb2c18fb6689199d053b1d50fa--