[PATCH] D93881: [llvm-objcopy] preserve file ownership when overwritten

Wed Jan 6 15:29:31 PST 2021

manojgupta added a comment.

In D93881#2483184 <https://reviews.llvm.org/D93881#2483184>, @MaskRay wrote:

> I don't think we want to introduce a filename based chmod API. Unless it is essential (very unlikely), it is easy for developers to make time-of-check time-of-use (TOCTOU) race condition allowing bypass of protection mechanism due to symlink attacks.
>
> binutils 2.36 will fix the issue https://sourceware.org/bugzilla/show_bug.cgi?id=26945

Can you please clarify what is being fixed, the use of internal renaming APIs or the current behavior?

> Regarding whether llvm-objcopy should adopt the GNU objcopy `smart_rename` behavior, I am a bit hesitant, somewhat inclining to no.
>
> It seems that very few packages actually require the behavior - most packages should use something like `install -o ... -g ... -m ... ` to copy files, the owner/group is not too useful.

We are hitting this problem in Portage (used in Gentoo Linux and Chrome OS) which is both a build system and a package manager. One of the steps after building a package is to install the files with the required permissions. And another action is to strip the files and add the debuginfo link etc. These steps execute as root privilege in portage as they modify the file system and we do not have control over it.

Because of the deviation from GNU objcopy/strip, stripping or just adding debuginfo link causes the "security sensitive" binaries to lose the intended permissions. We already had to revert twice switching to llvm objcopy/strip for this reason in Chrome OS before we figured out the problem. Therefore, I'd argue that this change is needed for GNU compatibility.
It is also what most tools already do when dealing with existing files e.g. "sudo vi foo.c" or "echo foo |& sudo tee a.c" does not change file ownership or group.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93881/new/

https://reviews.llvm.org/D93881