Skip site navigation (1)Skip section navigation (2)
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>