I'm getting the following failure when installing google-chrome-unstable: * Messages for package www-client/google-chrome-unstable-48.0.2564.8_p1: * QA Notice: The following files contain insecure RUNPATHs * Please file a bug about this at http://bugs.gentoo.org/ * with the maintaining herd of the package. * $ORIGIN/ /tmp/portage/www-client/google-chrome-unstable-48.0.2564.8_p1/image/opt/google/chrome-unstable/chrome-sandbox * ERROR: www-client/google-chrome-unstable-48.0.2564.8_p1::gentoo failed: * Aborting due to serious QA concerns with RUNPATH/RPATH I think is complaining about RPATH=$ORIGIN/ in the chrome-sandbox binary. 10executable-issues has this code segment: > # Reject set*id binaries with $ORIGIN in RPATH #260331 > x=$( > find "${ED}" -type f \( -perm -u+s -o -perm -g+s \) -print0 | \ > xargs -0 scanelf -qyRF '%r %p' | grep '$ORIGIN' > ) Bug 260331 says that normal users may create hard links to suid binaries, and these hard links maintain suid permissions. This is a problem since $ORIGN may be manipulated by a normal user. I just tested this on Linux 4.1.6, and I'm getting "Operation not permitted" when I try to create a hard link to any file owned by another user. So, the security problem posed in that bug seems to have been addressed in the kernel at some point. Is this QA check still relevant? Or can we remove it?
As a workaround, I'm stripping the RPATH from the chrome-sandbox binary with chrpath. It wasn't needed anyway.
i imagine that's a kernel setting because i can create hard links just fine to setuid files. even then, there's no guarantee the system won't run an older kernel which doesn't block it. ignoring that, use of $ORIGIN in set*id programs is still banned. it doesn't make sense and is simply a bad idea. see this upstream bug report about getting it fixed: http://crbug.com/556843
This was fixed some time ago upstream.
