[MacPorts] #49963: arb @6.0.1_3: LD_LIBRARY_PATH is undefined at make_arbperl_makefile.pl line 21

[MacPorts]

#49963: arb @6.0.1_3: LD_LIBRARY_PATH is undefined at make_arbperl_makefile.pl line
21
----------------------------+-----------------------------
  Reporter:  cruiz_perez@…  |      Owner:  matt.cottrell@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.3.4
Resolution:                 |   Keywords:  elcapitan
      Port:  arb            |
----------------------------+-----------------------------

Comment (by elmar@…):

 Just to explain exactly what's going on here:
 1. ARB passes the location of dynamic libraries to be used both during
 build and after installation using the environment variables
 `LD_LIBRARY_PATH` or `DYLD_LIBRARY_PATH`, depending on host OS. This
 approach has thus far been a fool-proof way to make sure than even with
 multiple versions of ARB installed and users moving ARB installations
 around, the dynamic linker always uses the correct set of libraries. It
 still works fine, even with SIP, except during build.
 2. As per POSIX.1 standard, which the Apple documentation claims their
 implementation adheres to (see `man /usr/share/man/man3/exec.3`), '''the
 environment for a new process image "shall" be a copy of the environment
 of the parent process''', or the array passed to `execle`.
 3. Apple's "SIP" '''breaks''' this behavior by '''deleting''' all
 variables matching `/LD_LIBRARY_PATH|DYLD_.*/` from the process images of
 binaries '''if''' they are loaded from a path flagged as protected (e.g.
 `/bin`, `/sbin`, `/usr`). This is not mentioned in any of the pertinent
 man files nor in the System Integrity Protection Guide on the Apple
 Developer website, nor anywhere else I checked.
 4. Gnu Make includes a hard coded path to `/bin/sh` to make sure all
 recipes are executed sanely and predictably, without interference by user
 configured environments. It ignores both the `PATH` and `SHELL`
 environment variables for this purpose, unless `SHELL` is explicitly set
 on the command line or in a loaded script.
 5. During the build, a Perl script is called from a Make recipe. The Gnu
 '''Make''' installed via MacPorts '''passes the recipe''' line calling
 Perl (also installed via MacPorts) '''to `/bin/sh`''' for expansion and
 execution. At this point, OS X's '''SIP interferes and deletes the library
 path variables''' from the environment. The Perl script then fails.

 > This is merely a workaround. The developers of arb should fix their
 build system so that it works even on El Capitan and later with SIP
 enabled and without workarounds like copying the shell.

 A behavior that is both unexpected and in conflict with the documentation
 is commonly called a bug. "Fixing" the issue within the ARB build system
 is therefore what I would call a workaround for a broken target
 platform/distribution.

 That said, ARB is already littered with workarounds for various target
 platforms anyway. In this case, however, the failing script is part of the
 code building the Perl bindings for the ARB database library. This is done
 using Perl's MakeMaker utility, which does frightening things like
 rebuilding its own Makefile and has been fragile in the past. In order to
 avoid regression on other platforms, I'd rather not rashly touch this
 part. If anyone wants to give it a try, please do. Do test on SLES, RHEL,
 Debian, Centos and Ubuntu as well, though.

 I would favor a fix on distribution level. Environment variables
 "mysteriously disappearing" between Make and the tool called from a
 Makefile recipe is just wrong. The suggestion to copy /bin/sh into a path
 not flagged for protection and setting SHELL in Makewas meant as a hot fix
 and as a means for verifying the source of the problem. A more general
 solution would be to make it so that MacPort's Gnu Make always uses a
 fully working shell, rather than /bin/sh. AFAIK this would require
 patching Gnu Make and/or adding a shell to its dependencies.

 As a more direct, short term fix, the ARB package could simply require
 Bash as a dependency and set PATH and SHELL appropriately to avoid usage
 of /bin/bash or /bin/sh (with SHELL set either on the Make command line or
 by adding a line to `config.makefile`.

 The sad part is that after it originally took me almost a day to figure
 out what was going on (the idea that some part of the OS was stealing
 variables didn't occur to me until everything else had been excluded), it
 took all of 5 seconds to work around it. I would love to see a discussion
 piece from Apple on why they thought this was a useful approach to improve
 security, more so than say the time honored method of linking high-value
 targets statically. Also, I'd love to hear in which scenarios an attack
 that is possible by getting a binary on the target host and modifying a
 processes' environment can be done using DYLD_LIBRARY_PATH and a malicious
 library, but not by modifying PATH and adding a malicious binary... (let's
 hope PATH isn't next up on Apple's list for lock down).

-- 
Ticket URL: <https://trac.macports.org/ticket/49963#comment:7>
MacPorts <https://www.macports.org/>
Ports system for OS X