From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10397 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: readdir(3): behavior on descriptors with O_SEARCH Date: Sun, 28 Aug 2016 09:10:52 +0200 Message-ID: <20160828071052.GA28382@voyager> References: 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 1472368271 12203 195.159.176.226 (28 Aug 2016 07:11:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 07:11:11 +0000 (UTC) User-Agent: Mutt/1.5.23 (2014-03-12) To: musl@lists.openwall.com Original-X-From: musl-return-10410-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 28 09:11:08 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 1bduFH-0002qV-MJ for gllmg-musl@m.gmane.org; Sun, 28 Aug 2016 09:11:07 +0200 Original-Received: (qmail 15360 invoked by uid 550); 28 Aug 2016 07:11:06 -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 14304 invoked from network); 28 Aug 2016 07:11:05 -0000 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K0:ZSwxem2BxiXU5FoW+ea11CSKrUT622qR/ymTQrO/PLrrJcsPsk3 I5GzAly9gpQsxKNS2Z5sjKSrC9UDAWyLbBIzB3DFte1bvDsyJqIlvFARGFzm9q0/yMjyqRk QmeR+lEVRGYDuPgLlf3b3f+8BHt2WCZA0k1MPmlbFvdYfhH+MD1uY+etsTTpgAwD6d1c1d2 IkD6Bz+2c7L5LI5P9a/Sw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ACz7VwMuZwo=:UClne5vKkuJhuN0kWHYbTC C64P579nFobR13oFxJ7Qb/oGfJenmcEhUBEANXTgb4DocW73DCO5vxKIv8oYOALKLa+iKiCNV 0xDiLK0BSBjp/b5uBCe4S7GXcHfHRK51gSZ8bq8vPhQ/2wk4oVkayLW8LaLq53nsaDxJj1WIP Yw4fAtFX4fK+HZ3kmbfZd+V3iYhx5uKgcyYMhYw8ONqzPPkxQF+0BBzPIJn2X0vEg3hxmdkRh CpH0fsGdrwrFV+yRHYg69maqr4G2pQbgmMLyRN+RP6HmsVaLhVFrhFnRVYvw+3Rj4jpyDWYuO k0rbCQ0IPQcOALqUThjcF03ZkkUakxasglhhOdzOETSRKOIkj0Hb/9AijKQnX54TeMDApPnga DKWjATE4e+i1/2LHHzFNwtj5xkgC8eQjkk4J2iQfGD5BtnjdhivkkrHI/Fq/2PYqs2k9/gxAZ GPvPXCu4N/DykveitUiTIeR/ljzw6J+27RtGF8sKe37XarH38GOmLgTRpeb2k8usBAACi3CqS BY8FLzMFkAZyu12tpYhhBGPOD7kUFKXzxs2WLK8/FW/LF4ciq4vToSkx0YHzGsVdFA3gSkA9Z 03nuH7Z7y+YYgWVlkxP7Zbq4QGX927UmSBcm7DntOzs1DID9lq6yJdmOQlHll4Vu1/CmpyhTt DuPYlzy/AfWV8Bay9wAUz01/JoW4thHiMcvSkH+q8v6dPfaoZiPVNm5ov2JvC0V0bBqFCkdwc FfMD1zKar5SJn6d4RlKlqV2UQndhK2T7FbZtcd2hAGC+SlewFmd8S4dPN5SEuBPze9E40YiD Xref: news.gmane.org gmane.linux.lib.musl.general:10397 Archived-At: On Sat, Aug 27, 2016 at 09:23:50PM +0300, Dmitry Selyutin wrote: > int const flags = (O_DIRECTORY | O_SEARCH); > int descriptor = open(path, flags); > DIR *handle = fdopendir(descriptor); > struct dirent *entry = readdir(handle); > > To cut the long story short, any attempt to call readdir(3) on directory > handle obtained via fdopendir(3) returns NULL and sets the errno variable > 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 "well, > 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 good > 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 their meaning. Ciao, Markus