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: <908066.1634251206@sss.pgh.pa.us>
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>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 14 Oct 2021 18:40:06 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <909288.1634252667.1@sss.pgh.pa.us>
Date: Thu, 14 Oct 2021 19:04:27 -0400
Message-ID: <909289.1634252667@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/909289.1634252667%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I recall that we figured out awhile ago that the environment gets trimmed
> when make (or whatever) executes some command via the shell; seemingly,
> Apple has decided that /bin/sh is a security-critical program that mustn't
> be run with a non-default DYLD_LIBRARY_PATH.  Dunno if that helps you
> find where the damage is done exactly.

BTW, here's the evidence for this theory:

[tgl@pro ~]$ cat checkenv.c
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char **argv)
{
  char *pth = getenv("DYLD_LIBRARY_PATH");

  if (pth)
    printf("DYLD_LIBRARY_PATH = %s\n", pth);
  else
    printf("DYLD_LIBRARY_PATH is unset\n");

  return 0;
}
[tgl@pro ~]$ gcc checkenv.c
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH is unset
[tgl@pro ~]$ export DYLD_LIBRARY_PATH=/Users/tgl/pginstall/lib
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
[tgl@pro ~]$ sh -c ./a.out
DYLD_LIBRARY_PATH is unset
[tgl@pro ~]$ ./a.out
DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
[tgl@pro ~]$ bash -c ./a.out
DYLD_LIBRARY_PATH is unset

You have to check the environment using an "unprivileged" program.
If you try to examine the environment using, say, "env", you will get
very misleading results.  AFAICT, /usr/bin/env is *also* considered
security-critical, because I cannot get it to ever report that
DYLD_LIBRARY_PATH is set.

Hmm ... /usr/bin/perl seems to act the same way.  It can see
ENV{'PATH'} but not ENV{'DYLD_LIBRARY_PATH'}.

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.

			regards, tom lane