Re: macOS SIP, next try

2021-03-08 Thread Peter Eisentraut
On 05.03.21 01:36, Tom Lane wrote: Hmm. So I tried this, ie "csrutil enable --without debug" in the recovery system, and after rebooting what I see is $ csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: disabled

Re: macOS SIP, next try

2021-03-04 Thread Tom Lane
Peter Eisentraut writes: > On 01.03.21 15:44, Tom Lane wrote: >> Peter Eisentraut writes: >>> I have since learned that there is a way to disable only the part of SIP >>> that is relevant for us. This seems like a useful compromise, and it >>> appears that a number of other open-source projects

Re: macOS SIP, next try

2021-03-03 Thread Peter Eisentraut
On 01.03.21 15:44, Tom Lane wrote: Peter Eisentraut writes: I have since learned that there is a way to disable only the part of SIP that is relevant for us. This seems like a useful compromise, and it appears that a number of other open-source projects are following the same route. I suggest

Re: macOS SIP, next try

2021-03-01 Thread Tom Lane
Peter Eisentraut writes: > I have since learned that there is a way to disable only the part of SIP > that is relevant for us. This seems like a useful compromise, and it > appears that a number of other open-source projects are following the > same route. I suggest the attached documentation

Re: macOS SIP, next try

2021-02-28 Thread Peter Eisentraut
So, we haven't gotten anywhere satisfying with these proposed technical solutions. I have since learned that there is a way to disable only the part of SIP that is relevant for us. This seems like a useful compromise, and it appears that a number of other open-source projects are following

Re: macOS SIP, next try

2021-01-22 Thread Tom Lane
BTW, a couple other things that should be noted here: * Per observation in a nearby thread, install_name_tool seems to be provided by Apple's "Command Line Tools", but not by Xcode. This is also true of bison and flex, but we don't require those in a build-from-tarball. So relying on install_name

Re: macOS SIP, next try

2021-01-05 Thread Tom Lane
Mark Dilger writes: > See also > https://www.postgresql.org/message-id/flat/18012hGLG6HJ9pQDkHAMYuwQKg%40sparkpost.com Yeah. As I recall from that thread and prior ones, the bottleneck is really just /bin/sh: something, either the kernel or sh itself, is clearing out DYLD_LIBRARY_PATH when a sh

Re: macOS SIP, next try

2021-01-04 Thread Mark Dilger
> On Dec 2, 2020, at 6:28 AM, Peter Eisentraut > wrote: > > Previous discussions on macOS SIP: > > https://www.postgresql.org/message-id/flat/561E73AB.8060800%40gmx.net > https://www.postgresql.org/message-id/flat/CA%2BTgmoYGi5oR8Rvb2-SY1_WEjd76H5gCqSukxFQ66qR7MewWAQ%40mail.gmail.com > https

Re: macOS SIP, next try

2021-01-04 Thread Tom Lane
Peter Eisentraut writes: > The solution here is to use install_name_tool to edit the shared library > path in the binaries (programs and libraries) after installation into > the temporary prefix. Ah, this indeed seems like a promising direction. > The solution is, I think, correct in principle

macOS SIP, next try

2020-12-02 Thread Peter Eisentraut
Previous discussions on macOS SIP: https://www.postgresql.org/message-id/flat/561E73AB.8060800%40gmx.net https://www.postgresql.org/message-id/flat/CA%2BTgmoYGi5oR8Rvb2-SY1_WEjd76H5gCqSukxFQ66qR7MewWAQ%40mail.gmail.com https://www.postgresql.org/message-id/flat/6a4d6124-41f0-756b-0811-c5c5def7ef4