Thread: [HACKERS] macOS Sierra & System Integrity Protection
I have a new MacBook Pro running Sierra. I managed to get PostgreSQL to build after install Xcode, installing MacPorts, installing the documentation toolchain via some incantation that was apparently wrong, and then uninstalling and reinstalling the documentation toolchain per https://trac.macports.org/ticket/44464 - but even after that, 'make check' was failing: 'psql' repeatedly died with an abort trap. Binaries worked fine when I ran them from the command line (sometimes with DYLD_LIBRARY_PATH, if needed) but when run via pg_regress, nothing worked. At first, I thought that the problem was just the /usr/lib/libpq.5.dylib which xcode had deposited, which I couldn't move out of the way without disabling System Integrity Protection, but eventually I got that done. However, getting that out of the way didn't fix anything: it turns out that System Integrity Protection feature *also* prevents DYLD_LIBRARY_PATH from being inherited by child processes in some manner. I *think* you can still set it for a process that you invoke directly, but it can't be passed down multiple levels. Because of that, psql, when run from the regression test environment, can't find libpq at all (or finds the one you already have installed rather than the one you just built), and bad stuff happens. So now I'm running with SIP disabled, and everything works fine. My main purpose in writing this email is to pass along what I learned in the hopes of sparing somebody else some trouble, but perhaps there is a way to modify our regression test setup so that the tests can pass with System Integrity Protection enabled. Disabling it requires booting into recovery mode and then rebooting back into regular mode, and is not recommended, so many users may find it inconvenient and unpalatable. ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > ... it turns out that System Integrity Protection > feature *also* prevents DYLD_LIBRARY_PATH from being inherited by > child processes in some manner. Yeah, this was already known and documented on the lists a year or two back. I suggest filing a bug report with Apple; if enough people bitch about it, maybe they'll rethink. (I don't have much hope for that, mind you, but they certainly won't change this without a boatload of complaints.) https://www.postgresql.org/message-id/26098.1446697005@sss.pgh.pa.us > My main purpose in writing this email is to pass along what I learned > in the hopes of sparing somebody else some trouble, but perhaps there > is a way to modify our regression test setup so that the tests can > pass with System Integrity Protection enabled. Not really. If you want it to take libpq.dylib from the build tree, rather than some already-installed location, there is no other option but DYLD_LIBRARY_PATH. The really annoying thing is that there's no particular security advantage to be gained by not passing it through bash invocations. If they're not resetting PATH in such cases, which they aren't, where the heck is the incremental gain from resetting DYLD_LIBRARY_PATH? A bad guy in control of the process environment has already won. regards, tom lane
On 6/12/17 23:38, Tom Lane wrote: > https://www.postgresql.org/message-id/26098.1446697005@sss.pgh.pa.us > >> My main purpose in writing this email is to pass along what I learned >> in the hopes of sparing somebody else some trouble, but perhaps there >> is a way to modify our regression test setup so that the tests can >> pass with System Integrity Protection enabled. > Not really. If you want it to take libpq.dylib from the build tree, > rather than some already-installed location, there is no other option > but DYLD_LIBRARY_PATH. I think the idea mentioned in the earlier thread about using relative rpaths would be worth a try. (Computing relative paths in makefile + shell might be fun.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 13 June 2017 at 04:25, Robert Haas <robertmhaas@gmail.com> wrote: > I have a new MacBook Pro running Sierra. Congratulations. > 'make check' was failing: 'psql' repeatedly died with an abort > trap. Binaries worked fine when I ran them from the command line > (sometimes with DYLD_LIBRARY_PATH, if needed) but when run via > pg_regress, nothing worked. I've not had that problem, though running it hasn't been trouble free. So I guess there must be some sequence of actions that works. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Simon Riggs <simon@2ndquadrant.com> writes:
> On 13 June 2017 at 04:25, Robert Haas <robertmhaas@gmail.com> wrote:
>> 'make check' was failing: 'psql' repeatedly died with an abort
>> trap. Binaries worked fine when I ran them from the command line
>> (sometimes with DYLD_LIBRARY_PATH, if needed) but when run via
>> pg_regress, nothing worked.
> I've not had that problem, though running it hasn't been trouble free.
> So I guess there must be some sequence of actions that works.
It works fine if you "make install" first, or if the install tree
exists and contains a copy of libpq.dylib that's not so old as to
break your test.
If you haven't got any install tree, the dynamic linker tries to
fall back on /usr/lib/libpq.dylib, which is too old, and you get
nasty core dumps.
regards, tom lane