[Bug dynamic-link/25263] New: ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/25263] New: ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25263

            Bug ID: 25263
           Summary: ldd and ld.so fail to resolve $ORIGIN with cross dir
                    symlink
           Product: glibc
           Version: 2.30
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: timj at gnu dot org
  Target Milestone: ---

Created attachment 12114
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12114&action=edit
Add realpath to ldd

In 2.27 and 2.30, ldd fails to find $ORIGIN relative libraries if the
executable is provided as a symlink from a different directory.

Example:

 mkdir foo && cd foo
 wget
https://github.com/electron/electron/releases/download/v7.1.3/electron-v7.1.3-linux-x64.zip
 unzip electron-v7.1.3-linux-x64.zip
 ldd electron | fgrep ffmpeg
        libffmpeg.so => /tmp/foo/./libffmpeg.so (0x0000154fae45e000)
 ln -s foo/electron ../electron
 ldd ../electron | fgrep ffmpeg
        libffmpeg.so => not found

One symptom is that tools that rely on ldd output for e.g. packaging like
linuxdeploy, fail to find dependent libraries for symlinked executables.
Note that it is really ld.so (used by ldd internally) that suffers from this
problem, using realpath fixes the problem:

 LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 ../electron |
   fgrep ffmpeg
        libffmpeg.so => not found
 LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 \
   $(realpath ../electron) | fgrep ffmpeg
        libffmpeg.so => /tmp/foo/libffmpeg.so (0x00001495d56e2000)

It might be ok for endusers if ld.so doesn't handle symlinks well, so a
possible bugfix could be adding realpath to just ldd, as shown in the attached
patch. With that, the lookup works as expected:

 ./ldd ../electron | fgrep ffmpeg
        libffmpeg.so => /tmp/foo/libffmpeg.so (0x00007faff35ad000)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/25263] ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25263

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Did this work with any previous glibc version? Does it make a difference if you
do not run the test from within /tmp? Thanks.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/25263] ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25263

--- Comment #2 from timj at gnu dot org ---
(In reply to Florian Weimer from comment #1)
> Did this work with any previous glibc version?

Not that I'm aware of. For me the bug surfaced now because what used to be a
binary under $prefix/bin/ became a link, and during AppImage packaging (with
linuxdeploy ... -e $prefix/bin/symlink) libraries started to be missing.

> Does it make a difference if
> you do not run the test from within /tmp? Thanks.

Nope, the problem originally surfaced in /var:

 $ ll /var/tmp/beast/out/appdir2//usr/bin/beast
 lrwxrwxrwx... /var/tmp/beast/out/appdir2//usr/bin/beast -> ../electron/ebeast*
 $ ldd /var/tmp/beast/out/appdir2//usr/bin/beast | fgrep ffmpeg
        libffmpeg.so => not found
 $ ldd /var/tmp/beast/out/appdir2//usr/bin/../electron/ebeast | fgrep ffmpeg
        libffmpeg.so =>
/var/tmp/beast/out/appdir2//usr/bin/../electron/libffmpeg.so
(0x000014c83f3eb000)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/25263] ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25263

--- Comment #3 from timj at gnu dot org ---
Just to be clear, this bug *only* happens when tracing libraries with
LD_TRACE_LOADED_OBJECTS=1.

There is *no* bug observed when starting executables with $ORIGIN via a cross
directory symlink (possibly because ld.so always has an absolute realpath to
operate on in this case).

That's why it can be sufficient to just patch ldd, so it only triggers ld.so
tracing on absolute realpath executables, i.e. the realpath that ld.so would
also operate on when starting the executable.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/25263] ldd and ld.so fail to resolve $ORIGIN with cross dir symlink

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25263

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
I believe this bug is the reason why it is not possible to invoke OpenJDK
binaries (such as /usr/bin/java) with an explicit ld.so invocation.

--
You are receiving this mail because:
You are on the CC list for the bug.