[HEADSUP] Disallowing read() of a directory fd

[Guido Falsi]

On 15/05/20 11:47, Stefan Eßer wrote:
> 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 at 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?
> 
> 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.
> 
>> 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)

Chiming in just to note that this is not a theoretical thing, I stumbled
upon such a problem of this a little time ago:

https://github.com/yarnpkg/yarn/issues/4884

-- 
Guido Falsi <mad at madpilot.net>