From owner-freebsd-standards@freebsd.org  Wed Jul  8 18:29:22 2020
Return-Path: <owner-freebsd-standards@freebsd.org>
Delivered-To: freebsd-standards@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 79B12369C90
 for <freebsd-standards@mailman.nyi.freebsd.org>;
 Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3])
 by mx1.freebsd.org (Postfix) with ESMTP id 4B27BB2jQbz4PMY
 for <freebsd-standards@freebsd.org>; Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: by mailman.nyi.freebsd.org (Postfix)
 id 5B31E369C27; Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
Delivered-To: standards@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 5AF7B3699D5
 for <standards@mailman.nyi.freebsd.org>; Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::19:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "mxrelay.nyi.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 4B27BB1hc2z4PcX
 for <standards@FreeBSD.org>; Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2610:1c1:1:606c::50:1d])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (Client did not present a certificate)
 by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1DBF9246B7
 for <standards@FreeBSD.org>; Wed,  8 Jul 2020 18:29:22 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org ([127.0.1.5])
 by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 068ITLo3047495
 for <standards@FreeBSD.org>; Wed, 8 Jul 2020 18:29:21 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
Received: (from bugzilla@localhost)
 by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 068ITLpb047494
 for standards@FreeBSD.org; Wed, 8 Jul 2020 18:29:21 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to
 bugzilla-noreply@freebsd.org using -f
From: bugzilla-noreply@freebsd.org
To: standards@FreeBSD.org
Subject: [Bug 246412] Return EISDIR when reading a directory
Date: Wed, 08 Jul 2020 18:29:22 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: commit-hook@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: kevans@freebsd.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-246412-99-rbGqCCOTqQ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-246412-99@https.bugs.freebsd.org/bugzilla/>
References: <bug-246412-99@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-standards@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: Standards compliance <freebsd-standards.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-standards>, 
 <mailto:freebsd-standards-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-standards/>
List-Post: <mailto:freebsd-standards@freebsd.org>
List-Help: <mailto:freebsd-standards-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-standards>, 
 <mailto:freebsd-standards-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 18:29:22 -0000

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246412

--- Comment #6 from commit-hook@freebsd.org ---
A commit references this bug:

Author: kevans
Date: Wed Jul  8 18:29:07 UTC 2020
New revision: 363017
URL: https://svnweb.freebsd.org/changeset/base/363017

Log:
  MFC r361798, r361800: vfs: default disallow read(2) of a directory

  This MFC is in accordance with the original MFC plan outlined in the comm=
it
  message for r361798, appearing in full (with exception to metadata) below.

  To summarize: this MFC only merges back the sysctl with a default disallow
  policy, as in head, to ensure we hit any issues quickly but in a fashion
  that end users can easily revert. Interested parties can flip the
  security.bsd.allow_read_dir sysctl back to 1 to fully honor the previous
  behavior of allowing read(2) of any dir, filesystem permitting.

  r361798:
  vfs: add restrictions to read(2) of a directory [1/2]

  Historically, we've allowed read() of a directory and some filesystems wi=
ll
  accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed =
by
  Warner: <<EOF

  pdp-7 unix seemed to allow reading directories, but they were weird, spec=
ial
  things there so I'm unsure (my pdp-7 assembler sucks).

  1st Edition's sources are lost, mostly. The kernel allows it. The
  reconstructed sources from 2nd or 3rd edition read it though.

  V6 to V7 changed the filesystem format, and should have been a warning, b=
ut
  reading directories weren't materially changed.

  4.1b BSD introduced readdir because of UFS. UFS broke all directory readi=
ng
  programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and
  friends were introduced here.

  SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 upda=
ted
  all the directory reading programs in 1988 because different filesystem
  types were introduced.

  In the 90s, these interfaces became completely ubiquitous as PDP-11s runn=
ing
  V7 faded from view and all the folks that initially started on V7 upgraded
  to SysV. Linux never supported this (though I've not done the software
  archeology to check) because it has always had a pathological diversity of
  filesystems.
  EOF

  Disallowing read(2) on a directory has the side-effect of masking
  application bugs from relying on other implementation's behavior
  (e.g. Linux) of rejecting these with EISDIR across the board, but allowing
  it has been a vector for at least one stack disclosure bug in the past[0].

  By POSIX, this is implementation-defined whether read() handles directori=
es
  or not. Popular implementations have chosen to reject them, and this seems
  sensible: the data you're reading from a directory is not structured in s=
ome
  unified way across filesystem implementations like with readdir(2), so it=
 is
  impossible for applications to portably rely on this.

  With this patch, we will reject most read(2) of a dirfd with EISDIR. Users
  that know what they're doing can conscientiously set
  bsd.security.allow_read_dir=3D1 to allow read(2) of directories, as it has
  proven useful for debugging or recovery. A future commit will further lim=
it
  the sysctl to allow only the system root to read(2) directories, to make =
it
  at least relatively safe to leave on for longer periods of time.

  While we're adding logic pertaining to directory vnodes to vn_io_fault, an
  additional assertion has also been added to ensure that we're not reaching
  vn_io_fault with any write request on a directory vnode. Such request wou=
ld
  be a logical error in the kernel, and must be debugged rather than allowi=
ng
  it to potentially silently error out.

  Commented out shell aliases have been placed in root's chsrc/shrc to prom=
ote
  awareness that grep may become noisy after this change, depending on your
  usage.

  A tentative MFC plan has been put together to try and make it as trivial =
as
  possible to identify issues and collect reports; note that this will be
  strongly re-evaluated. Tentatively, I will MFC this knob with the default=
 as
  it is in HEAD to improve our odds of actually getting reports. The future
  priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the kn=
ob
  will be a faithful reversion on stable/12. We will go into the merge
  acknowledging that the sysctl default may be flipped back to restore
  historical behavior at *any* point if it's warranted.

  [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc

  r361800:
  RELNOTES and UPDATING: Document the new policy on read(2) of dirfd

  These changes have been completely flushed as of r361799; note it.

  PR:           246412
  Relnotes:     yes 100%

Changes:
_U  stable/12/
  stable/12/UPDATING
  stable/12/bin/csh/dot.cshrc
  stable/12/lib/libc/sys/read.2
  stable/12/sys/kern/vfs_vnops.c

--=20
You are receiving this mail because:
You are on the CC list for the bug.=