Date: Fri, 15 May 2020 11:47:44 +0200 From: =?UTF-8?Q?Stefan_E=c3=9fer?= <se@freebsd.org> To: Arne Steinkamm <arne@Steinkamm.COM> Cc: freebsd-arch@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <e5a21dd4-6c53-2dca-8fa8-387e2532b7c8@freebsd.org> In-Reply-To: <20200515011258.GW82984@trajan.stk.cx> References: <CACNAnaFszg%2BQWPRS0kghsnQMxXc%2B5niPTTNiUPSmK60YyBGCzA@mail.gmail.com> <202005142017.04EKH0aA093503@fire.js.berklix.net> <CAOtMX2i2Z-KX=3rYR2nZ1g1Lb_tF==H3xPKcQMBxJs1Kqr-meQ@mail.gmail.com> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhs@berklix.com> 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? 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. > 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) - 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. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e5a21dd4-6c53-2dca-8fa8-387e2532b7c8>