Bug 702909 - Build system mishandles ORIGIN-based runpath
Summary: Build system mishandles ORIGIN-based runpath
Status: RESOLVED LATER
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 9.53.1
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-16 06:52 UTC by Jeffrey Walton
Modified: 2022-11-16 09:12 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2020-09-16 06:52:47 UTC
Hi Everyone. I'm building ghostpdl-9.53.1.tar.gz on Ubuntu 18.04 x86_64 fully patched. It looks like the build system is mishandling ORIGIN-based runpaths.

This is from a script I use to audit binaries after installation:

  $ ./audit-rpath-bins.sh ~/tmp/ok2delete/bin
  ...
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/gxps:

  (RUNPATH) [/../lib:/home/jwalton/tmp/ok2delete/lib]
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/gs:

  (RUNPATH) [/../lib:/home/jwalton/tmp/ok2delete/lib]
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/gpcl6:

  (RUNPATH) [/../lib:/home/jwalton/tmp/ok2delete/lib]

My LDFLAGS has the following flags. It looks like '$ORIGIN/../lib' is being munged.

  LDFLAGS: -L/home/jwalton/tmp/ok2delete/lib -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/home/jwalton/tmp/ok2delete/lib -Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,origin

We have to pass '$ORIGIN/../lib' in LDFLAGS because Autotools features test runs its tests using LDFLAGS. However, later, when makefiles are written, the '$' (dollar sign) needs to be escaped because '$' is a special character in a makefile. That is, when makefiles are written, the makefile should use '$$ORIGIN/../lib'.

Autotools usually handles this for you (escaping '$' in makefiles). I'm not sure why it is not being handled for you in this case.

I have a script that fixes mishandled escapes in makefiles: https://github.com/noloader/Build-Scripts/blob/master/fix-makefiles.sh. I run it after './configure' to escape '$ORIGIN' to '$$ORIGIN'. The script is not fixing them either. That makes me believe _all_ makefiles are not written after './configure'. I've seen that happen when makefiles are written on the fly, and I never have an opportunity to fix them.

The other possibility is the makefiles don't have CPPFLAGS, CFLAGS and LDFLAGS written at configure time. In this case, a Makefile is called with the flags set at build time. That is, 'make CPPFLAGS=...' CFLAGS='...' LDFLAGS='...''. In this case, the dollar signs need to be escaped before calling make. GhostScript needs to something like this: https://github.com/noloader/Build-Scripts/blob/master/build-bzip.sh#L117.

You can manually audit RPATHs and RUNPATHs with:

    readelf -d "$file" | grep -E 'RPATH|RUNPATH'

**********

The mishandling of runpaths is a problem for two reasons. First, Musl's loader throws away all runpaths if one RPATH or RUNPATH is wrong. That means the wrong library will be loaded at runtime on systems like Alpine Linux.

Second, '/../lib' will probably evaluate to just '/lib' on some platforms. That means the wrong library will be loaded at runtime. On Solaris, that means '/lib/bzip.so' will be loaded. And as fate has it, Oracle did not patch '/lib/bzip.so', and there are two outstanding CVEs.

**********

Here is what a successful audit looks like:

  $ ./audit-rpath-bins.sh ~/tmp/ok2delete/bin
  ...
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/openssl:

  (RUNPATH) [$ORIGIN/../lib:/home/jwalton/tmp/ok2delete/lib]
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/tset:

  (RUNPATH) [$ORIGIN/../lib:/home/jwalton/tmp/ok2delete/lib]
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/msgen:

  (RUNPATH) [$ORIGIN/../lib:/home/jwalton/tmp/ok2delete/lib]
  ****************************************
  /home/jwalton/tmp/ok2delete/bin/infocmp:

  (RUNPATH) [$ORIGIN/../lib:/home/jwalton/tmp/ok2delete/lib]
Comment 1 Peter Cherepanov 2021-01-02 02:50:49 UTC
Google finds only one site that has "audit-rpath-bins.sh". Please give an example of a platform where Ghostscript does not build.
Comment 2 Jeffrey Walton 2021-01-02 03:25:58 UTC
(In reply to Peter Cherepanov from comment #1)
> Google finds only one site that has "audit-rpath-bins.sh".

That's probably my Build Scripts at https://github.com/noloader/Build-Scripts.

> Please give an
> example of a platform where Ghostscript does not build.

Ubuntu 18.05, x86_64. Another is Solaris 11.3, i86pc. Yet another is CentOS 5, x86_64. None of them handle RUNPATHs properly.
Comment 3 Chris Liddell (chrisl) 2021-12-01 16:32:55 UTC
I have a admit, I can't see a way to make this work reliably. And I can't see any way, anywhere that autotools would handle it.

Basically, every time the "value" of LDFLAGS is assigned, the variable expansion will happen, and we do that in various places for a number of reasons.
Comment 4 Chris Liddell (chrisl) 2022-11-16 09:12:34 UTC
After digging into this again, I really feel this is a limitation of autoconf and co more than a specific problem with the Ghostscript build.

I'm therefore changing this to "Later", so it won't be forgotten.