file permissions when stripping under fakeroot

[Fangrui Song]

On 2021-02-07, Alan Modra via Binutils wrote:
>On Sun, Feb 07, 2021 at 02:39:51PM +1000, Allan McRae via Binutils wrote:
>> >From local testing, glibc-2.33 appears to be needed in combination with
>> binutils-2.36.1 for this issue to occur.  This would explain the issue
>> being present on rawhide and not on release Fedora versions.
>
>Note that for a very long time, if you objcopy/strip a file when you
>lack write permission for the file then ownership can change.  eg.
>
>$ gcc -o hello -g ~/src/tmp/hello.c
>$ sudo chown root. hello
>[sudo] password for alan:
>$ ls -l hello
>-rwxr-xr-x 1 root root 18392 Feb  7 16:19 hello
>$ strip hello
>ls -l hello
>-rwxr-xr-x 1 alan alan 14312 Feb  7 16:20 hello
>
>This shouldn't be surprising at all.
>
>$ sudo chown root. hello
>[sudo] password for alan:
>$ ls -l hello
>-rwxr-xr-x 1 root root 14312 Feb  7 16:20 hello
>$ cp -p hello hello.new
>$ rm -f hello
>$ mv hello.new hello
>$ ls -l hello
>-rwxr-xr-x 1 alan alan 14312 Feb  7 16:20 hello

strip creates a temporary file and does a rename for such "fake-in-place" modification.
Arguably distributions should not rely on the root chown/fchown behavior.
(what's the extend to which attributes are preserved? What about xattr? :))

If distributions need such a behavior, they could explicitly obtain owner/group
and restore it.
https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng/m/ZlqM-QC6BQAJ

(
I am fairly suspicious when ChromeOS folks wanted to port such a root chown behavior to llvm-strip, so I chatted with Rich, who reported
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 ...
)