svn commit: r361238 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Kyle Evans]

On Tue, May 19, 2020 at 10:23 AM Rodney W. Grimes
<freebsd at gndrsh.dnsmgr.net> wrote:
>
> > Author: kevans
> > Date: Tue May 19 02:41:05 2020
> > New Revision: 361238
> > URL: https://svnweb.freebsd.org/changeset/base/361238
> >
> > Log:
> >   zfs: reject read(2) of a dirfd with EISDIR
> >
> >   This is independent of the recently-discussed global change, which is still
> >   in review/discussion stage.
> >
> >   This is effectively a measure for consistency in the ZFS world, where
> >   FreeBSD was the only platform (as far as I could find) that allowed this.
> >   What ZFS exposes is decidedly not useful for any real purposes, to
> >   paraphrase (hopefully faithfully) jhb's findings when exploring this:
> >
> >   The size of a directory in ZFS is the number of directory entries within.
> >   When reading a directory, you would instead get the leading part of its raw
> >   contents; the amount you get being dictated by the "size," i.e. number of
> >   directory entries. There's decidedly (luckily) no stack disclosure happening
> >   here, though the behavior is bizarre and almost certainly a historical
> >   accident.
> >
> >   This change has already been upstreamed to OpenZFS.
>
> Until the grep -d skip issue is addressed I object to this change as
> it is going to cause people who do grep with wildcards to see lots
> of errors that before where pretty much either silent (no match occured)
> or spit out a "binary file foo matches."
>

That seems preferable to grepping random bytes that don't particularly
contain any strings? They'd never see "binary file foo matches" in
this case.

This isn't exactly divergent from the behavior they'd see with ZFS
anywhere else.

Thanks,

Kyle Evans