Date: Thu, 04 Jun 2020 18:10:44 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 246412] Return EISDIR when reading a directory Message-ID: <bug-246412-99-Y1TMeLDMTK@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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246412 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: kevans Date: Thu Jun 4 18:09:57 UTC 2020 New revision: 361798 URL: https://svnweb.freebsd.org/changeset/base/361798 Log: 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 PR: 246412 Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous) Reviewed by: rgrimes (latest version) MFC after: 1 month (note the MFC plan mentioned above) Relnotes: absolutely, but will amend previous RELNOTES entry Differential Revision: https://reviews.freebsd.org/D24596 Changes: head/bin/csh/dot.cshrc head/bin/sh/dot.shrc head/lib/libc/sys/read.2 head/sys/kern/vfs_vnops.c --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246412-99-Y1TMeLDMTK>