#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