Subject: bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

From: George Valkov <[email-masked]>
Date: Wed, 15 Feb 2023 17:26:21 +0200

> On 2023-02-15, at 12:56 PM, Paul Eggert <[email-masked]> wrote:
> 
> The disabling SEEK_HOLE on Apple is OK if a release is imminent. Otherwise I'd like to get to the bottom of it first. This can be done by having George use dtrace or (if that's not possible) adding debugging printfs.

Hi Paul! Sure, send me some code, describe the tests you need and I will come back with the results. Since we are tracing regular programs and not system components, dtruss can be used. Here is a trace of the sparse copy sample I wrote earlier, when it tries to copy cc1 to cc1-sparse, resulting in a corrupted copy:
https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/dtruss-sparse-copy.txt

> Attached is an updated proposal for the fclonefileat patch.
> 
> CVE-2021-30995 confirmed my suspicion that coreutils 9.1 and the current bleeding-edge coreutils on Savannah both have an exploitable security bug on macOS. Although I hope this patch fixes the bug, it could use more pairs of eyes, given that Apple had so many problems fixing its own security bug involving fclonefileat, and given that the coreutils code has so many flags and conditions.
> <0001-cp-fclonefileat-security-fix-CLONE_ACL-fixups.patch>

I tested your patch: both overwrite existing and clone to new produce a working copy. Here are the test results:
https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-04-cf80f988eeb97cc3f8c65ae58e735d36f865277b-clone.txt

In the case when a dangling symlink is involved and depending on the arguments passed to cp, would it be possible to use CLONE_NOFOLLOW with fclonefileat or fall-back to a normal copy? Does dangling refer to source or destination?

Georgi Valkov
httpstorm.com
nano RTOS