From owner-freebsd-arch@freebsd.org Fri May 15 09:47:48 2020 Return-Path: Delivered-To: freebsd-arch@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 BA4262F050D; Fri, 15 May 2020 09:47:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nk9J4HMHz4bVv; Fri, 15 May 2020 09:47:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300CD5F25D600ACFE788A6E98E203.dip0.t-ipconnect.de [IPv6:2003:cd:5f25:d600:acfe:788a:6e98:e203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 23C5618E86; Fri, 15 May 2020 09:47:47 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: [HEADSUP] Disallowing read() of a directory fd References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: freebsd-arch@freebsd.org, FreeBSD Hackers To: Arne Steinkamm Message-ID: Date: Fri, 15 May 2020 11:47:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200515011258.GW82984@trajan.stk.cx> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 09:47:48 -0000 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 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) - currently we make no guarantee with regard to success or failure of reading a directory - it depends on the choice made by the file system (and technical limitations, e.g. in case of NFS) - information could be leaked that is of use to an attacker (and that might have been the main reason it has been prohibited in OpenBSD) Every script run by an unprivileged user ought to be able to deal with a directory that cannot be read e.g. because of insufficient privilege. A script run by root should never depend on unspecified behavior (even if in case that it has been defined behavior in BSD for a long time). I'm convinced that there is more code today that has been developed on Linux and breaks on FreeBSD, unless specifically patched, then there are shell scripts that break when directory access is limited to the access functions provided for this purpose for decades. I've always been a strong supporter of POLA, but do not see how this suggested change is going to be a violation of that principle. We could make this change in -CURRENT, not MFC at all or after a long period of testing whether there is any fall-out, and then decide whether we want it backed out or controller by a tunable or sysctl. Such an experiment in -CURRENT (announced on the appropriate lists) should not cause any trouble or churn for developers and let us find out, if there really is some negative impact. Regards, STefan