From owner-freebsd-hackers@freebsd.org Fri May 15 12:47:47 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 626D12F4B22; Fri, 15 May 2020 12:47:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Np8y51MYz3JBC; Fri, 15 May 2020 12:47:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 04FClh3b086498; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 04FClhsD086497; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-Reply-To: To: =?UTF-8?Q?Stefan_E=C3=9Fer?= Date: Fri, 15 May 2020 05:47:43 -0700 (PDT) CC: Arne Steinkamm , freebsd-arch@freebsd.org, FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49Np8y51MYz3JBC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.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 12:47:48 -0000 > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: > > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > >> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > >> > >>> Kyle Evans wrote: > >>>> Hi, > >>>> > >>>> This is a heads up, given that I'm completely flipping our historical > >>>> behavior- I intend to commit this review in a couple days' time > >>>> without substantial objection: https://reviews.freebsd.org/D24596 > >>>> > >>>> With this, FreeBSD 13 will not allow read() of a directory fd, which > >>>> could have previously returned some data from the underlying > >>>> filesystem in no particular standardized format. > >>>> > >>>> This is a still-standards-compliant switch from one > >>>> implementation-defined behavior to another that's already been adopted > >>>> in various other popular kernels, to include OpenBSD, MacOS, and > >>>> Linux. > >>>> > >>>> Worth noting is that there's not really one largely-compelling reasons > >>>> to switch this after so many years (unless you find yourself that > >>>> irate when you accidentally `cat` a directory), but there are some > >>>> benefits which are briefly discussed in the commentary around the > >>>> review along with the history of the current behavior. > >>>> > >>>> This change also simplifies filesystem implementations to some extent. > >>>> > >>>> Thanks, > >>>> > >>>> Kyle Evans > >>> > >>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! > >>> > >>> "cat ." as been supported since Unix V6 1978 or earlier, > >>> no problem, even occasionaly useful. > >>> > >> > >> Really? When is that occasionally useful? I've never seen anything useful > >> come out of reading a directory. > > > > It's all about files in Unix... > > > > This is true since 1972. > > > > And files can be read! > > > > How many (bad programmed) shell scripts will break when directory files can't > > be read anymore? I have no idea. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? I believe there is some confusion over what the symantics of read means on a directory and what is being changed, and file protections. This change does not change the actual protection on a directory, so the effect on if [ -r ${pathname} ]; is none. > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. The use case is usually an emergency and these options are generally not very viable solutions. > > > But I know for sure that there is no need to make this change. > > Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Thats actually a bad reason, as this only allows non portable code to remain non portable without consequence. > > - currently we make no guarantee with regard to success or failure of > reading a directory - it depends on the choice made by the file system > (and technical limitations, e.g. in case of NFS) > > - information could be leaked that is of use to an attacker (and that > might have been the main reason it has been prohibited in OpenBSD) > > Every script run by an unprivileged user ought to be able to deal with a > directory that cannot be read e.g. because of insufficient privilege. > > A script run by root should never depend on unspecified behavior (even > if in case that it has been defined behavior in BSD for a long time). > > I'm convinced that there is more code today that has been developed on > Linux and breaks on FreeBSD, unless specifically patched, then there are > shell scripts that break when directory access is limited to the access > functions provided for this purpose for decades. > > I've always been a strong supporter of POLA, but do not see how this > suggested change is going to be a violation of that principle. > > > We could make this change in -CURRENT, not MFC at all or after a long > period of testing whether there is any fall-out, and then decide whether > we want it backed out or controller by a tunable or sysctl. > > Such an experiment in -CURRENT (announced on the appropriate lists) > should not cause any trouble or churn for developers and let us find > out, if there really is some negative impact. I can support this change so long as there is a *RUN* time way to disable it for root which does not require a reboot of any kind. Much like Kirk, and Poul who have pointed out a use cases when doing a UFS data recovery this is a usefull feature. Often the directory tree is valid, but the file names are mangled. -- Rod Grimes rgrimes@freebsd.org