Date: Fri, 15 May 2020 05:47:43 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: =?UTF-8?Q?Stefan_E=C3=9Fer?= <se@freebsd.org> Cc: Arne Steinkamm <arne@Steinkamm.COM>, freebsd-arch@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> In-Reply-To: <e5a21dd4-6c53-2dca-8fa8-387e2532b7c8@freebsd.org>
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? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202005151247.04FClhsD086497>