From owner-freebsd-hackers@freebsd.org Fri May 15 23:09:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 949EC2DD115; Fri, 15 May 2020 23:09:33 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49P3yN40Gkz4bWr; Fri, 15 May 2020 23:09:32 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.206.8 Received: from bec.de (p5799CE08.dip0.t-ipconnect.de [87.153.206.8]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 16009E0004; Fri, 15 May 2020 23:09:29 +0000 (UTC) Date: Sat, 16 May 2020 01:09:28 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515230928.GA9126@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> <20200515202526.GZ82984@trajan.stk.cx> <20200515220923.GA36597@bec.de> <20200515224724.WFACq%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515224724.WFACq%steffen@sdaoden.eu> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 49P3yN40Gkz4bWr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.196) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[196.183.70.217.rep.mailspike.net : 127.0.0.18]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bec.de]; AUTH_NA(1.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[8.206.153.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(-1.58)[ip: (-5.01), ipnet: 217.70.176.0/20(-1.61), asn: 29169(-1.29), country: FR(-0.00)]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[196.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:09:33 -0000 On Sat, May 16, 2020 at 12:47:24AM +0200, Steffen Nurpmeso wrote: > Joerg Sonnenberger wrote in > <20200515220923.GA36597@bec.de>: > |On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote: > |> On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > |>> It's been 42 or more years since this bug was introduced. Let's \ > |>> just fix it > |>> now instead of agonizing over it. > |> > |> I didn't want to add something as everything is said, > |> but this sentence is a little bit to provocative. > |> > |> Everything is a file describes one of the defining features of Unix. > |> > |> Calling this defining feature of Unix a bug shows to me that the ideas > |> behind Unix got lost in the FreeBSD universe too... > | > |Using linear storage for a directory is an implementation detail of the > |implementation. It's not a defining feature. "Reading" from a directory > |doesn't make sense for many other organisational forms. So, are you now > |arguing that leaky abstractions are a defining feature of Unix? > > In an ideal Unix world read(2)ing from a directory fd would do the > job that getdents(2) / getdirentries(2) never moved to a standard, > leaving us with that terrible readdir(3) stuff. imho. That still doesn't work well with non-linear representations of directories. readdir has issues, but plain read is even worse. Joerg