Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Jan 2022 17:29:57 -0800
From: Farid Zakaria <>
Cc: "Scogland, Tom" <>,, 
	Carlos Maltzahn <>
Subject: is RUNPATH being incorrectly inherited inherited?


I'm observing a strange behavior and it seems to contradict what[1] says should be the case for RUNPATH, namely I am observing
that musl's dynamic linker seems to use the DT_RUNPATH of the
executable when searching for entries of its children.

> Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.  Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries.  This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.

I've uploaded a Makefile[2] that you can use to follow along.

First let's build the binary. It's designed to depend on two shared
libraries _libx.so_ and _liby.so_; _liby.so_ also depends on _libx.so_

Note: that I make the top-level _libx.so_ an absolute path using patchelf.

# build it
$ make CC=musl-gcc

# let's inspect it to see what it looks like
# here we can see the needed, including the one absolute
$ patchelf --print-needed exe

# here is the RUNPATH
$ patchelf --print-rpath exe

# an alternate query
$ objdump -x ./exe | grep RUNPATH
  RUNPATH              $ORIGIN/b:$ORIGIN/

# here is a dependent library
$ patchelf --print-needed b/

# has no RUNPATH
objdump -x b/| grep RUNPATH

I would expect this *to not work* since there is no way for to
discover, especially given the previous correspondence on the
mailing lists on how musl does not utilize soname for the cache.

However you can see that the linker is trying to resolve _libx.so_
using the RUNPATH when it is loading _liby.so_

$ strace -e openat,stat,open ./exe
+++ exited with 0 +++

Harmen's libtree[3] already fails to find the library.
$ libtree exe
├── [direct]
└── .//b/ [runpath]
    └── not found
        ┊ Paths considered

To me this means that the here is not respecting the description
of not propagating the search paths to the children.

FWIW, as per the other correspondence, if I remove part of the
RUNPATH, then the binary fails to load even though _libx.so_ was
already present.

$ patchelf --print-rpath exe

$ /exe
Error loading shared library No such file or directory
(needed by /home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/

Thank you.


Powered by blists - more mailing lists

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