another look at macOS SIP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

another look at macOS SIP

Peter Eisentraut-6
I have figured out another solution to the problem that macOS SIP
defeats the use of DYLD_LIBRARY_PATH for running the temp-install
regression tests.  It's not without problems either, but it might show a
path forward.

First of all, I think I now know the exact mechanism by which this
breakage happens.

The precise issue is that /bin/sh filters out DYLD_* environment
variables (presumably all, but at least the ones we care about) when it
starts.  If you use a shell other than /bin/sh (say, a Homebrew
installation of bash or dash), there is no problem.

But /bin/sh is hardcoded in the system() library call, so in order to
fix that, you need to override that library call.  Attached is a patch
that shows how this could be done.  It uses the DYLD_INSERT_LIBRARIES
environment variable (equivalent to LD_PRELOAD) to substitute another
version of system(), which I hacked to allow overriding /bin/sh with
another shell using the environment variable PG_REGRESS_SHELL.  That works.

There are also some other places where PostgreSQL code itself hardcodes
/bin/sh as part of system()-like functionality.  These have to be fixed
up similarly, but that's easier.

The problem now is that DYLD_INSERT_LIBRARIES requires the "flat
namespace", which isn't the default.  You can either build PostgreSQL
with -Wl,-flat_namespace, which works, but it's probably weird as a
proper solution, or you can set the environment variable
DYLD_FORCE_FLAT_NAMESPACE at run time, which also works but makes
everything brutally slow.

I think the way forward here is to get rid of all uses of system() for
calling between PostgreSQL programs.  There are only a handful of those,
and we already have well-tested replacement code like spawn_process() in
pg_regress.c that could be used.  (Perhaps we could also use that
opportunity to get rid of the need for shell quoting?)

There is a minor second issue, namely that /usr/bin/perl also filters
out DYLD_* environment variables.  This can be worked around again by
using a third-party installation of Perl.  You just need to make sure
that the "prove" program calls that installation instead of the system
one.  (I just manually edited the shebang line.  There is probably a
proper way to do it.)

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

0001-Make-temp-install-tests-work-with-macOS-SIP.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Tom Lane-2
Peter Eisentraut <[hidden email]> writes:
> I have figured out another solution to the problem that macOS SIP
> defeats the use of DYLD_LIBRARY_PATH for running the temp-install
> regression tests.  It's not without problems either, but it might show a
> path forward.
> ...
> The precise issue is that /bin/sh filters out DYLD_* environment
> variables (presumably all, but at least the ones we care about) when it
> starts.

Yeah, that was pretty much what we'd speculated.

> I think the way forward here is to get rid of all uses of system() for
> calling between PostgreSQL programs.

We could do that perhaps, but how are you going to get make to not use
/bin/sh while spawning subprocesses?  I don't think we want to also
reimplement make ...

> There is a minor second issue, namely that /usr/bin/perl also filters
> out DYLD_* environment variables.  This can be worked around again by
> using a third-party installation of Perl.

This is not sounding better than just turning off SIP :-(

We could, however, probably fix things so that our Perl test scripts
re-establish those environment variables internally.  We don't need
the perl processes themselves to load test libraries, just their
descendants.

Maybe a similar workaround is possible for the "make" issue?
I have a feeling it would be less flexible than what we have
today, though.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Peter Eisentraut-6
On 2019-09-10 19:26, Tom Lane wrote:
>> I think the way forward here is to get rid of all uses of system() for
>> calling between PostgreSQL programs.
>
> We could do that perhaps, but how are you going to get make to not use
> /bin/sh while spawning subprocesses?  I don't think we want to also
> reimplement make ...

make is not a problem if the DYLD_* assignments are in a makefile rule
(as currently), because then make just calls a shell with a string
"DYLD_*=foo some command", which is not affected by any filtering.  It
would be a problem if you do the variable assignments in a makefile
outside a rule or outside a makefile.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Andres Freund
In reply to this post by Peter Eisentraut-6
Hi,

On 2019-09-10 19:14:19 +0200, Peter Eisentraut wrote:
> I think the way forward here is to get rid of all uses of system() for
> calling between PostgreSQL programs.  There are only a handful of those,
> and we already have well-tested replacement code like spawn_process() in
> pg_regress.c that could be used.  (Perhaps we could also use that
> opportunity to get rid of the need for shell quoting?)

Yea, I think that'd be good, regardless of SIP.


> There is a minor second issue, namely that /usr/bin/perl also filters
> out DYLD_* environment variables.  This can be worked around again by
> using a third-party installation of Perl.  You just need to make sure
> that the "prove" program calls that installation instead of the system
> one.  (I just manually edited the shebang line.  There is probably a
> proper way to do it.)

Hm, could we just have perl code set DYLD_* again? I assume we don't
need prove itself to have it set, and for the testscripts we could just
set it in TestLib.pm or such?


Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Tom Lane-2
Andres Freund <[hidden email]> writes:
> On 2019-09-10 19:14:19 +0200, Peter Eisentraut wrote:
>> There is a minor second issue, namely that /usr/bin/perl also filters
>> out DYLD_* environment variables.  This can be worked around again by
>> using a third-party installation of Perl.

> Hm, could we just have perl code set DYLD_* again? I assume we don't
> need prove itself to have it set, and for the testscripts we could just
> set it in TestLib.pm or such?

Yeah, that's what I was suggesting.  "Use another copy of Perl" doesn't
seem like an acceptable answer, or at least it's hardly better than
"turn off SIP".

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Peter Eisentraut-6
On 2019-09-17 21:43, Tom Lane wrote:
> Yeah, that's what I was suggesting.  "Use another copy of Perl" doesn't
> seem like an acceptable answer, or at least it's hardly better than
> "turn off SIP".

In my mind, the Perl aspect of this is the most trivial part of the
problem.  "brew install perl" is probably faster than writing out this
email.  But I suppose everyone has their own workflows.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Tom Lane-2
Peter Eisentraut <[hidden email]> writes:
> On 2019-09-17 21:43, Tom Lane wrote:
>> Yeah, that's what I was suggesting.  "Use another copy of Perl" doesn't
>> seem like an acceptable answer, or at least it's hardly better than
>> "turn off SIP".

> In my mind, the Perl aspect of this is the most trivial part of the
> problem.  "brew install perl" is probably faster than writing out this
> email.  But I suppose everyone has their own workflows.

There's a not-insignificant contingent that don't wish to install
either homebrew or macports.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: another look at macOS SIP

Robert Haas
In reply to this post by Andres Freund
On Tue, Sep 17, 2019 at 1:52 PM Andres Freund <[hidden email]> wrote:
> On 2019-09-10 19:14:19 +0200, Peter Eisentraut wrote:
> > I think the way forward here is to get rid of all uses of system() for
> > calling between PostgreSQL programs.  There are only a handful of those,
> > and we already have well-tested replacement code like spawn_process() in
> > pg_regress.c that could be used.  (Perhaps we could also use that
> > opportunity to get rid of the need for shell quoting?)
>
> Yea, I think that'd be good, regardless of SIP.

+1, and making some progress on the SIP issue would be good, too, even
if we don't fix everything right away.  It seems entirely possible
that Apple will make this even more annoying to disable than it
already is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company