From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32554 invoked from network); 13 Jan 2022 01:30:24 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Jan 2022 01:30:24 -0000 Received: (qmail 28311 invoked by uid 550); 13 Jan 2022 01:30:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28274 invoked from network); 13 Jan 2022 01:30:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xiCcmykg8SL5kUGNvilXCsoAianeOWpdzVQaL/oXFfQ=; b=GL3qGHo8DK4hXrZQNwtZEOzpq/EJXoNsB89t2roYXTpoK7nRIuGgN6dP/7Pm4wp4Ym Tjom+/pr36BuO7NH5m7hP1hNDEbPV0nt68siC13ulWyr7vilNZrXu2z1Cy78AE/RLxsX HSVL/KgNnD9LPCmUVMM8uzomV0gnacy1ZFngFoaXagBI+FHC/RsffLIXO5z0ZPUkkIhZ ut6hHtRzGGM4BG34MeTSXkSXJb9IxOfhwuzh5vKzHP0R7uosmv9DrnMjRl5oAkngmhSN TwbiK56xMqPBulmBMpvfIiQJ7EVYC3AoleRFHafeILnUYpzHpAfCttvMdPCy7/WvsR0X ZxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xiCcmykg8SL5kUGNvilXCsoAianeOWpdzVQaL/oXFfQ=; b=QvEM1olyZ00a3XUzXMBixkPIyoeATrosGuZWNR5qQbrl+/2lHAyHDjWl2dmestEMox gmN49ouEnXTh3Mx0ORd6sJNs6NRw4fQh4Uciaib7nLO1vWIZMGynIEeBdgUT50aBrZeq Ckc1sSP6yvALnbMn8W0Hbc4TuBv3JgCy49L+r+if3Hhfpq67wXNqIYEe8TxHeoi5sSSe 8+F2BW5qGNuqYM8s6tqLSn8WkvwwVOarBcT9pwJAcyR/lj8Rhwa05qnLnZ/ZrEuzyW4S LPwU/CfXMcd2tRH6/delqgUnqPXYQWX7dYnaV74zZ5/6sD8+SndigTBjkiI2CjZztfX+ bgJg== X-Gm-Message-State: AOAM530NiHPz1djMDMqYuGgKPDWyJqp6nWNwhNKDQqcmkLwEIKdjynRS lH81HZ9ZgK/baQj0ZQQ6JaMFSedYC1cj7tjFRzWCPftmE94EzQ== X-Google-Smtp-Source: ABdhPJwLfts3x6SzFHRVSC/g+991B+0wBAC+wVmo7q9Wd905oieMxO2yFFbnFkiQ2v9ft0n1pxfoIgWiipP9nsM93Ng= X-Received: by 2002:a25:8e89:: with SMTP id q9mr3618761ybl.520.1642037408184; Wed, 12 Jan 2022 17:30:08 -0800 (PST) MIME-Version: 1.0 From: Farid Zakaria Date: Wed, 12 Jan 2022 17:29:57 -0800 Message-ID: To: musl@lists.openwall.com Cc: "Scogland, Tom" , me@harmenstoppels.nl, Carlos Maltzahn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [musl] is RUNPATH being incorrectly inherited inherited? Hello, I'm observing a strange behavior and it seems to contradict what ld.so[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 attribu= te of the binary if present. Such directories are searched only to find th= ose objects required by DT_NEEDED (direct dependencies) entries and do not = apply to those objects' children, which must themselves have their own DT_R= UNPATH 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=3Dmusl-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 liby.so /home/fzakaria/code//c/libx.so libc.so # here is the RUNPATH $ patchelf --print-rpath exe $ORIGIN/b:$ORIGIN/c # an alternate query $ objdump -x ./exe | grep RUNPATH RUNPATH $ORIGIN/b:$ORIGIN/ # here is a dependent library $ patchelf --print-needed b/liby.so libx.so libc.so # liby.so has no RUNPATH objdump -x b/liby.so| grep RUNPATH ``` I would expect this *to not work* since there is no way for liby.so to discover libx.so, 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 open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/lib= y.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) =3D 3 open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/c/lib= x.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) =3D 3 open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/lib= x.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) =3D -1 ENOENT (No such file or directory) open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/c/lib= x.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) =3D 3 24 +++ exited with 0 +++ ``` Harmen's libtree[3] already fails to find the library. ``` $ libtree exe exe =E2=94=9C=E2=94=80=E2=94=80 libx.so [direct] =E2=94=94=E2=94=80=E2=94=80 .//b/liby.so [runpath] =E2=94=94=E2=94=80=E2=94=80 libx.so not found =E2=94=8A Paths considered ``` To me this means that the ld.so 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 $ORIGIN/b $ /exe Error loading shared library libx.so: No such file or directory (needed by /home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/= b/liby.so) ``` Thank you. [1] https://man7.org/linux/man-pages/man8/ld.so.8.html [2] https://gist.github.com/fzakaria/375f2c27f2db000369ec49a684ef8095 [3] https://github.com/haampie/libtree