Change Details

Historically, we've allowed read() of a directory and some filesystems will accommodate (e.g. ffs, msdosfs, zfs), but this can and has caused weird bugs when applications start to rely on other implementation's behavior (e.g. Linux) of rejecting these with EISDIR across the board. By POSIX, this is implementation-defined whether read() handles directories or not. Popular implementations have chosen to reject them, and this seems sensible: the data you're reading from a directory would seem to not be structured in some unified way across filesystem implementations like with readdir(2), so it seems really hard to rely on this. This is just a request for comments, though; I lean towards changing our historical behavior for 13.0, but I do not have the wisdom of years of filesystem experience.

Historically, we've allowed read() of a directory and some filesystems will accommodate (e.g. ufs/ffs, msdosfs). Some history, courtesy of Warner: ${COPY AND PASTE OF ALL OF IMP'S STATEMENTS} 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 directories or not. Popular implementations have chosen to reject them, and this seems sensible: the data you're reading from a directory would seem to not be structured in some unified way across filesystem implementations like with readdir(2), so it seems really hard to 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=1 to allow non-jailed root alone to read(2) directories, as it has proven useful for debugging or recovery. [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc

Historically, we've allowed read() of a directory and some filesystems will accommodate (e.g. ffs, msdosfsufs/ffs, zfs),msdosfs). but this can and has caused weird bugs when applications start to rely on other implementation's behavior (e.g.Some history, Linux) of rejecting these with EISDIR across the board.courtesy of Warner: ${COPY AND PASTE OF ALL OF IMP'S STATEMENTS} 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 directories or not. Popular implementations have chosen to reject them, and this seems sensible: the data you're reading from a directory would seem to not be structured in some unified way across filesystem implementations like with readdir(2), so it seems really hard to rely on this. This is just a request for commentsWith this patch, though;we will reject most read(2) of a dirfd with EISDIR. I lean towards changing our historical behavior for 13.0Users that know what they're doing can conscientiously set bsd.security.allow_read_dir=1 to allow non-jailed root alone to read(2) directories, but I do not have the wisdom of years of filesystem experience.as it has proven useful for debugging or recovery. [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc