file permissions when stripping under fakeroot

[Alan Modra]

On Mon, Feb 08, 2021 at 11:56:11AM +0530, Siddhesh Poyarekar wrote:
> 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.

Yes, I considered doing that myself.  I defer to Nick on this one
though.

> 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.

I wouldn't make any special cases.  Simple, if it works, is nearly
always better than complicated.

-- 
Alan Modra
Australia Development Lab, IBM