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