Обсуждение: [PATCH] make check with Apple's SIP enabled
Hi! When doing a "make check" on Mac OS X with SIP (aka rootless mode) enabled it will fail like this: ----- >8 snip 8< ----- rm -rf ./testtablespace mkdir ./testtablespace PATH="/Volumes/Home/arbeit/port25/postgresql-clean/tmp_install/usr/local/pgsql/bin:$PATH" DYLD_LIBRARY_PATH="/<path_to_postgresql_dir>/tmp_install/usr/local/pgsql/lib" ../../../src/test/regress/pg_regress --temp-instance=./tmp_check --inputdir=. --bindir= --dlpath=. --max-concurrent-tests=20 --schedule=./parallel_schedule ============== creating temporary instance ============== ============== initializing database system ============== ============== starting postmaster ============== sh: line 1: 81758 Trace/BPT trap: 5 "psql" -X postgres < /dev/null 2> /dev/null sh: line 1: 81762 Trace/BPT trap: 5 "psql" -X postgres < /dev/null 2> /dev/null sh: line 1: 81765 Trace/BPT trap: 5 "psql" -X postgres < /dev/null 2> /dev/null sh: line 1: 81768 Trace/BPT trap: 5 "psql" -X postgres < /dev/null 2> /dev/null sh: line 1: 81771 Trace/BPT trap: 5 "psql" -X postgres < /dev/null 2> /dev/null ^Cmake[1]: *** [check] Interrupt: 2 make: *** [check] Interrupt: 2 ----- >8 snap 8< ----- The problem is that the psql links to libpq which it cannot find (at least not the one from the postgres you're building). The usual approach to set an environment variable pointing to the correct location (DYLD_LIBRARY_PATH on Mac OS X/darwin, see above) does not work since Apple's SIP prevents it from getting passed to psql (see https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html ) What I do in the attached patch is changing the install name of libpq in the psql binary of the temp install (used by "make check") to point to libpq of the temp install so the (correct) lib is found. For not duplicating the information I created a new file "Makefile.libdefs" to where I extracted the information needed to do the install name change This patch has only been tested on Mac OS X El Capitan (10.11.6) since I currently have no other OS available Please let me know what you think of it Jörg
Вложения
On Fri, Jan 19, 2018 at 9:54 AM, Jörg Westheide <joerg.westheide@sparkpost.com> wrote: > When doing a "make check" on Mac OS X with SIP (aka rootless mode) enabled > it will fail like this: I don't know whether this fix is any good, but thanks for working on the problem. It's a very annoying problem, and I'd love to see it solved somehow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
=?iso-8859-1?Q?J=F6rg?= Westheide <joerg.westheide@sparkpost.com> writes: > When doing a "make check" on Mac OS X with SIP (aka rootless mode) > enabled it will fail like this: > ... Yeah, well-known problem. AFAIK, all PG developers who use Macs just disable SIP immediately. > The problem is that the psql links to libpq which it cannot find (at > least not the one from the postgres you're building). The usual > approach to set an environment variable pointing to the correct > location (DYLD_LIBRARY_PATH on Mac OS X/darwin, see above) does not > work since Apple's SIP prevents it from getting passed to psql Yup. This is incredibly brain-damaged and unnecessary on Apple's part. Several of us have filed bugs about it, and generally not gotten much response. Perhaps if people keep complaining, though, eventually they'll see the light. > What I do in the attached patch is changing the install name of libpq > in the psql binary of the temp install (used by "make check") to point > to libpq of the temp install so the (correct) lib is found. Cute idea, but AFAICS it would at most fix "make check" and not any tests that required other executables, or libraries besides libpq. Plus there's the objection that then you're not really testing the binary you intend to deploy. I suppose if we got invasive enough, we could extend this concept to every trouble spot, but I don't much want to go there. IIRC, the fact that SIP loses DYLD_LIBRARY_PATH is sort of accidental. It's not that they've broken the variable altogether, it's that when we invoke the shell to invoke psql, they clear out DYLD_LIBRARY_PATH because of some weird decision that the shell is a security-critical program. (As if the ability to invoke a shell with your choice of input didn't already give you the chance to do, far more easily, anything you might do by subverting the shell internally.) So it might be possible to dodge this problem, at least for "make check" and other pg_regress-driven cases, by changing pg_regress to avoid going through system(3) but rather fork-and-exec'ing psql directly. Nobody's pursued that idea, in part because we've generally found that SIP breaks enough other stuff that you have to keep it turned off anyway on development machines. But if you're interested, you could have a look at how messy that would be. regards, tom lane