file permissions when stripping under fakeroot
Siddhesh Poyarekar
siddhesh@gotplt.org
Mon Feb 8 06:26:11 GMT 2021
On 2/8/21 11:08 AM, Eli Schwartz via Binutils wrote:
>> 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 ...
>> )
>
> xattr has always been a problem, since strip always removed this for us.
>
> At any rate the Arch solution to this entire situation is to use
> strip/objcopy's -o outfile option to write our own temporary file, then
> cat it into the original file. This *preserves* ownership rather than
> recreating it (whether fakeroot is capable of picking up on it or not)
> and, for the first time ever, preserves xattrs too.
>
> https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9aad5bc4d8e170
>
> So our use case for packaging under fakeroot is no longer affected (once
> this change percolates to a release).
This sounds like never doing a rename+chown would be the best way to
keep everyone happy. Alan, would you accept such an approach? That
would comprehensively resolve this issue.
The downside is that the writing out the result may become noticeably
slower for large files. Maybe we could retain the rename for cases
where the source and destination have identical permissions, but xattr
will always be problematic.
Siddhesh
More information about the Binutils
mailing list