From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Andres Freund <andres@anarazel.de>,
        John Naylor <john.naylor@enterprisedb.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [RFC] building postgres with meson
In-reply-to: 
 <CA+hUKGKaB5UvE2rVk2adYNWKkahvX5AK+9CJ8x5_34kJXJ9+dw@mail.gmail.com>
References: <20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de>
 <CAFBsxsHwt7fvLKMCNkJQex-TpYb+CuX1RSBxbCEQ4Lb_FtgsVA@mail.gmail.com>
 <20211012205945.tkr6nam4ej2swram@alap3.anarazel.de>
 <CAFBsxsGOeT1cKp6iVjTTWQL+Vwt3cZgV4nOK2+zju4OLv6+TmA@mail.gmail.com>
 <20211013163721.oqwvztktwsym3iu4@alap3.anarazel.de>
 <CAFBsxsEqZ1cCayUEd6nS7sS9Pv29G-hkJLbqE1wUmtG1AP4xcg@mail.gmail.com>
 <20211013174246.zgp2sxdqsulhepea@alap3.anarazel.de>
 <CAFBsxsF2oeU3VUkB-TtvuJXAvyxHAQcweHDPAO0EC=e4BgC=yQ@mail.gmail.com>
 <CAFBsxsHfwZYDUOa1+KuW21WDJr+ONscE5ATgvfEBO7mgJHuWPA@mail.gmail.com>
 <D0B73C41-FA4E-40B9-870E-60852CC9D2E2@anarazel.de>
 <906095.1634248849@sss.pgh.pa.us>
 <CA+hUKGJcPZoJgQuwF3NOxymg6KW6azChcjFXB4fgbLQFBSXy0A@mail.gmail.com>
 <908066.1634251206@sss.pgh.pa.us> <909289.1634252667@sss.pgh.pa.us>
 <CA+hUKGKaB5UvE2rVk2adYNWKkahvX5AK+9CJ8x5_34kJXJ9+dw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Fri, 15 Oct 2021 13:36:28 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <920450.1634265967.1@sss.pgh.pa.us>
Date: Thu, 14 Oct 2021 22:46:07 -0400
Message-ID: <920451.1634265967@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/920451.1634265967%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> On Fri, Oct 15, 2021 at 12:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This may indicate that they've applied this policy on a blanket
>> basis to everything in /bin and /usr/bin (and other system
>> directories, maybe), rather than singling out the shell.

> Looks like it.  If I've found the right code here, it looks like where
> any common-or-garden Unix runtime linker would ignore LD_LIBRARY_PATH
> for a setuid binary, they've trained theirs to whack DYLD_*, and also
> for code-signed and __RESTRICT-marked executables.
> https://github.com/opensource-apple/dyld/blob/master/src/dyld.cpp#L1681

Ugh.  That explains it, all right.

> I suppose you could point SHELL at an unsigned copy of sh (codesign
> --remove-signature, or something from brew/ports/x) so that GNU make
> should respect, but I don't know how many other exec("/bin/sh") calls
> might be hiding around the place (I guess perl calls system()?) and
> might require some kind of LD_PRELOAD hackery... not much fun.

Yeah.  I thought about invoking everything via a small wrapper
that restores the correct setting of DYLD_LIBRARY_PATH.  We could
perhaps make that work for the invocations of test postmasters
and psqls from "make" and TAP scripts, but hacking up our code's
sundry uses of system(3) like that seems like it'd be very messy,
if feasible at all.

BTW, the POSIX spec explicitly discourages letting SHELL affect the
behavior of system(3), so I bet that wouldn't help.

			regards, tom lane