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

[George Valkov]

> On 2023-02-15, at 12:56 PM, Paul Eggert <eggert@cs.ucla.edu> 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