** Summary changed: - Handling $ORIGIN strings within DT_NEEDED sections + Handling $ORIGIN strings within DT_NEEDED entries
** Description changed: What documentation says: - "$ORIGIN sequences within a DT_NEEDED entry or path passed as a parameter to dlopen() are treated as errors." - (From "System V Application Binary Interface - DRAFT - 10 June 2013" / "Chapter 5 - Program Loading and Dynamic Linking" / "Dynamic Linking" / "Shared Object Dependencies" / "Substitution Sequences" <http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution>.) + From what documentation says, it looks like $ORIGIN string should be recognized within DT_NEEDED entries. + (Sorry, in initial version of bug-report I misinterpreted one of sentences in documentation, taking it out of context.) + See "System V Application Binary Interface - DRAFT - 10 June 2013" / "Chapter 5 - Program Loading and Dynamic Linking" / "Dynamic Linking" / "Shared Object Dependencies" / "Substitution Sequences" <http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution>. What in reality happens: - - Having $ORIGIN string within DT_NEEDED section with shared library that DOES NOT uses versioning, causes '$ORIGIN' to be interpreted as path-to-directory-where-binary-is-located (despite, per documentation, it should/must be treated as error). - - Having $ORIGIN string within DT_NEEDED section with shared library that USES versioning, causes assertion failure (see below) or segmentation fault (not on my system) (however, it doesn't look like intentional/graceful message related to explicitly documented case of ORIGIN within DT_NEEDED — it more looks like that ld.so was put into unexpected state). + - Having $ORIGIN string within DT_NEEDED entry and shared library that DOES NOT uses versioning, causes '$ORIGIN' to be interpreted as path-to-directory-where-binary-is-located. + - Having $ORIGIN string within DT_NEEDED entry and shared library that USES versioning, causes assertion failure (see below) or segmentation fault (not on my system). On my system, having $ORIGIN within DT_NEEDED together with versioning causes the following output: "Inconsistency detected by ld.so: dl- version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!". Some other people say they observe segmentation fault instead. I used the attached script test-origin-in-needed.sh to test behavior. I'd better report the bug to libc maintainers (upstream). Because it - seems to be upstream-related specification violation. But the libc bug - reporting policy says: "Distributions may include their own - modifications to glibc in the binaries and sources you get with the - operating system. If the glibc you are using comes from a complete - operating system distribution, you should report bugs to that - distribution project first." So, I report here first. + seems to be not downstream-related. But the libc bug reporting policy + says: "Distributions may include their own modifications to glibc in the + binaries and sources you get with the operating system. If the glibc you + are using comes from a complete operating system distribution, you + should report bugs to that distribution project first." So, I report + here first. 1) lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 - 2) pt-cache policy libc6 + 2) apt-cache policy libc6 libc6: - Installed: 2.23-0ubuntu4 - Candidate: 2.23-0ubuntu4 - Version table: - *** 2.23-0ubuntu4 500 - 500 http://ua.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages - 100 /var/lib/dpkg/status - 2.23-0ubuntu3 500 - 500 http://ua.archive.ubuntu.com/ubuntu xenial/main amd64 Packages + Installed: 2.23-0ubuntu4 + Candidate: 2.23-0ubuntu4 + Version table: + *** 2.23-0ubuntu4 500 + 500 http://ua.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages + 100 /var/lib/dpkg/status + 2.23-0ubuntu3 500 + 500 http://ua.archive.ubuntu.com/ubuntu xenial/main amd64 Packages - 3) I expected handling of $ORIGIN strings within DT_NEEDED sections to - be conforming "System V Application Binary Interface". Or, at least, to - see non-conforming parts explicitly documented somewhere in GNU - documentation. + 3) I expected $ORIGIN strings within DT_NEEDED entries to be either + recognized or not recognized. - 4) See above. Having $ORIGIN string within DT_NEEDED section without - versioning causes $ORIGIN to work as if it's within (for example) RPATH - section — violates documentation. Having $ORIGIN string within DT_NEEDED - section with versioning causes assertion failure (formally doesn't - violate documentation, but really it looks more like unexpected state - than graceful condition handling). I used attached script to test. + 4) Behavior depends on whether shared object is versioned or not. With + non-versioned shared object it seems to be ok. With versioned shared + object it causes assertion failure (or segmentation fault on some other + platforms). ** Description changed: What documentation says: From what documentation says, it looks like $ORIGIN string should be recognized within DT_NEEDED entries. (Sorry, in initial version of bug-report I misinterpreted one of sentences in documentation, taking it out of context.) See "System V Application Binary Interface - DRAFT - 10 June 2013" / "Chapter 5 - Program Loading and Dynamic Linking" / "Dynamic Linking" / "Shared Object Dependencies" / "Substitution Sequences" <http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution>. What in reality happens: - Having $ORIGIN string within DT_NEEDED entry and shared library that DOES NOT uses versioning, causes '$ORIGIN' to be interpreted as path-to-directory-where-binary-is-located. - Having $ORIGIN string within DT_NEEDED entry and shared library that USES versioning, causes assertion failure (see below) or segmentation fault (not on my system). On my system, having $ORIGIN within DT_NEEDED together with versioning causes the following output: "Inconsistency detected by ld.so: dl- version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!". Some other people say they observe segmentation fault instead. I used the attached script test-origin-in-needed.sh to test behavior. I'd better report the bug to libc maintainers (upstream). Because it seems to be not downstream-related. But the libc bug reporting policy says: "Distributions may include their own modifications to glibc in the binaries and sources you get with the operating system. If the glibc you are using comes from a complete operating system distribution, you should report bugs to that distribution project first." So, I report here first. 1) lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 2) apt-cache policy libc6 libc6: Installed: 2.23-0ubuntu4 Candidate: 2.23-0ubuntu4 Version table: *** 2.23-0ubuntu4 500 500 http://ua.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.23-0ubuntu3 500 500 http://ua.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 3) I expected $ORIGIN strings within DT_NEEDED entries to be either - recognized or not recognized. + always recognized or not recognized. 4) Behavior depends on whether shared object is versioned or not. With non-versioned shared object it seems to be ok. With versioned shared object it causes assertion failure (or segmentation fault on some other platforms). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1646822 Title: Handling $ORIGIN strings within DT_NEEDED entries To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646822/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
