[MacPorts] #49963: arb @6.0.1_3: LD_LIBRARY_PATH is undefined at make_arbperl_makefile.pl line 21
noreply at macports.org
Tue Apr 26 12:41:33 PDT 2016
#49963: arb @6.0.1_3: LD_LIBRARY_PATH is undefined at make_arbperl_makefile.pl line
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
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>
Ports system for OS X
More information about the macports-tickets