musl - Dynamic linking of NEEDED with absolute path differs than that of glibc

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH4OOv6b3AnNJOb_3ezW2GSBZdghrXGAp2BMFpH-jxbGW-wscQ@mail.gmail.com>
Date: Tue, 21 Dec 2021 10:56:33 -0800
From: Farid Zakaria <fmzakari@...c.edu>
To: musl@...ts.openwall.com
Cc: "Scogland, Tom" <scogland1@...l.gov>, Carlos Maltzahn <carlosm@...c.edu>
Subject: Dynamic linking of NEEDED with absolute path differs than that of glibc

Hello!

I am working, along with Tom <scogland1@...l.gov> on a contribution to
patchelf[1] that takes all the NEEDED from downstream shared object
dependencies and lifts them to the top executable. I then change the
NEEDED in the top executable to be absolute paths. This seems to work
as expected in glibc.

Please use this example for demonstrations:

Here I have two shared objects libbar and libfoo, where foo depends on bar.
```
> patchelf --print-needed libbar.so
libc.so.6
> patchelf --print-soname libbar.so
libbar.so

> patchelf --print-needed libfoo.so
libbar.so
libc.so.6
```

I then add libbar and libfoo to another executable but reference them
in NEEDED with explicit paths.
```
> patchelf --print-needed tests/scratch/replace-add-needed/simple
/some-fixed-path/libbar.so
/some-fixed-path/libfoo.so
/lib/x86_64-linux-gnu/libc.so.6
```

glibc seems to happily link this and the executable runs.
```
ldd ./tests/scratch/replace-add-needed/simple
linux-vdso.so.1 (0x00007ffc98d98000)
/some-fixed-path/libbar.so (0x00007f269b6d3000)
/some-fixed-path/llibfoo.so (0x00007f269b6ce000)
/lib/x86_64-linux-gnu/libc.so.6 (0x00007f269b509000)
/lib64/ld-linux-x86-64.so.2 (0x00007f269c6e3000)
```

If I do the same however with musl it doesn't seem to link and
complains about not finding libbar.so
```
ldd ./tests/scratch/replace-add-needed/simple
/lib/ld-musl-x86_64.so.1 (0x7f04dd7cd000)
/some-fixed-path/libbar.so (0x7f04dc7bf000)
/some-fixed-path/libfoo.so (0x7f04dc7ba000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f04dd7cd000)
Error loading shared library libbar.so: No such file or directory
(needed by /some-fixed-path/libfoo.so)
```

Tom helped track this down due to the shortname assignment behavior[2]

This is clearly safer than what it was doing before that, but would
musl be open to either:
 1 - Using the contents of DT_SONAME if set, which matches the
behavior of glibc at least from observation, or
 2- Using a shortname based on the basename of the path even for
path-based loading?

It also seems that there are issues similar to this on the mailing
list recently as well [3] and a bit of a discussion from Rich
on the Julia Github repository that sounds similar [4].

Thank you!
Farid Zakaria

[1] https://github.com/NixOS/patchelf
[2] https://github.com/rofl0r/musl/commit/0420b874465db7544a9e1f320969b4920c9405d8
[3] https://www.openwall.com/lists/musl/2021/12/16/1
[4] https://github.com/JuliaLang/julia/issues/40556#issuecomment-929713727

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.