[Bug 1646822] Re: Handling $ORIGIN strings within DT_NEEDED entries

Oleksandr Pikozh o.pikozh at gmail.com
Fri Dec 2 18:06:43 UTC 2016 

** 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
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1646822

Title:
  Handling $ORIGIN strings within DT_NEEDED entries

Status in glibc package in Ubuntu:
  New

Bug description:
  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
  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646822/+subscriptions

More information about the foundations-bugs mailing list