From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] building postgres with meson |
Date: | 2021-10-15 00:36:28 |
Message-ID: | CA+hUKGKaB5UvE2rVk2adYNWKkahvX5AK+9CJ8x5_34kJXJ9+dw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 15, 2021 at 12:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [tgl(at)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(at)pro ~]$ gcc checkenv.c
> [tgl(at)pro ~]$ ./a.out
> DYLD_LIBRARY_PATH is unset
> [tgl(at)pro ~]$ export DYLD_LIBRARY_PATH=/Users/tgl/pginstall/lib
> [tgl(at)pro ~]$ ./a.out
> DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
> [tgl(at)pro ~]$ sh -c ./a.out
> DYLD_LIBRARY_PATH is unset
> [tgl(at)pro ~]$ ./a.out
> DYLD_LIBRARY_PATH = /Users/tgl/pginstall/lib
> [tgl(at)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.
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
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-10-15 01:15:17 | Re: Added schema level support for publication. |
Previous Message | Masahiko Sawada | 2021-10-15 00:05:07 | Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES |