Re: Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or directory
control: retitle -1 ld-linux.so fails to expand relative RPATH when /proc is not mounted
control: tag -1 - security
Hi,
On 2015-05-30 18:56, Helmut Grohne wrote:
> Control: severity -1 wishlist
> Control: reassign -1 libc6
> Control: retitle -1 ld-linux.so loads libraries from . when /proc is not mounted
> Control: affects -1 + ghc
> Control: summary -1 0
>
> When /proc is not mounted, a relative RPATH causes ld-linux.so to fall
> back to using the working directory as the base directory for RPATH
> resolution instead of using the (unknown) location of the executed
> binary. This issue is hard to diagnose, because the error message does
> not make it clear that fallback code is in use due to readlink
> /proc/self/exe failing. Furthermore, it may pose a security risk by
> loading libraries from unintended locations.
The fact that it replaces $ORIGIN by the current directory when /proc is
not mounted is one part of the issue. It has already been tracked and
fixed in #884615.
> On Sat, May 30, 2015 at 11:54:26AM -0400, Joey Hess wrote:
> > Sorry, I meant the linker should be fixed, not ghc.
>
> Let's codify that in the bts.
>
> Steps to reproduce (for glibc maintainers):
>
> Create an unstable chroot. Install ghc. Do not mount /proc in that
> chroot. Execute /usr/bin/ghc. You shall see that it fails loading
> libraries.
>
> I assume that any binary with a relative RPATH is affected.
This is the second part of the issue. The dynamic loader has no way to
find the location of the binary without a mounted /proc, that's why it
fails to find the GHC libraries.
Retitling / tagging the bug accordingly.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: