In binutils, objcopy/strip perform smart_rename for "in-place" strip exe
and objcopy exe. smart_rename calls chown(2) (vulnerable:
https://sourceware.org/bugzilla/show_bug.cgi?id=26945) which requires
additional care to restore file modes and owner/group.
binutils 2.37 is moving to use truncate+overwrite
https://sourceware.org/pipermail/binutils/2021-February/115282.html
It has nice properties that owner/group/mode/security context/xattr are all
preserved. The downside is ETXTBSY (while the executable is running) and
potentially corrupted output in the case of full disk situation and other
erroneous cases.
This patch emulates its behavior when input filename = output filename
(llvm-strip exe, llvm-strip exe -o exe)[1]. llvm-objcopy/llvm-strip
treats '-' as stdin/stdout so '-' needs to be excluded from this behavior.
In addition, the implementation of --build-id-link-{input,out} (not in binutils,
contributed by Fuchsia but not in-use) needs the on-disk file so they should be excluded as well.
Changing owner/group requires privilege to test. I merely strengthen the existing file mode tests.
[1]: I'd like to just check whether -o is present, but it would need more code, and it probably does not matter to additionally make llvm-strip exe -o exe special while llvm-strip exe -o ./exe follows our original behavior.
Are there any particular reasons we need to use memory buffer instead of creating a temporary file? Will this be a problem for large binary files?