[Bug 1646822] [NEW] Handling $ORIGIN strings within DT_NEEDED sections

[Oleksandr Pikozh]

Public bug reported:

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>.)

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).

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.

1) lsb_release -rd
Description:    Ubuntu 16.04.1 LTS
Release:        16.04

2) pt-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 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.

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.

** Affects: glibc (Ubuntu)
     Importance: Undecided
         Status: New

** Attachment added: "test-origin-in-needed.sh"
   https://bugs.launchpad.net/bugs/1646822/+attachment/4786412/+files/test-origin-in-needed.sh

-- 
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 sections

Status in glibc package in Ubuntu:
  New

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

  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).

  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.

  1) lsb_release -rd
  Description:    Ubuntu 16.04.1 LTS
  Release:        16.04

  2) pt-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 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.

  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.

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