mapping process and mapped file (non-platform) have different Team IDs

Hi,


We package an Open Source database system called PostgreSQL. This is signed and notarized by us. PostgreSQL is designed to be user extensible, and has various hooks to allow additional functionality to be loaded from shared libraries, which are dynamically loaded at runtime.


We compile the PostgreSQL sources on macOS Mountain Lion (10.8) using MacOSX10.9.sdk with -mmacosx-version-min=10.9. The codesigning is done on the macOS Mojave (10.14) using a Developer ID Application certificate.


When linking with the hardened runtime, the loading of third-party extensions is blocked on macOS Catalina because they are not signed by either Apple or with the same team ID used for PostgreSQL itself. How can we resolve this such that our builds of PostgreSQL are able to load third-party extensions? We used the entitlement "com.apple.security.cs.disable-library-validation" already on the command line option for the codesign binary while signing the app bundle.


Awaiting your feedback. Thanks.

Replies

These extensions are being blocked by library validation, one of the many security features enabled by the hardened runtime. You can opt out of library validation with the

com.apple.security.cs.disable-library-validation
entitlement. See my Signing a Mac Product For Distribution post for instructions on how to apply entitlements.

We used the entitlement

com.apple.security.cs.disable-library-validation
already on the command line option for the codesign binary while signing the app bundle.

It’s hard to say why this is not working but I suspect that you’re either not setting this correctly or setting it on the wrong program.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks so much for your response and help. Now, instead of just applying the entitlements on the app bundle, I applied it on all the bundled binaries (postgres, pg_ctl, etc), .so and the dependent .dylibs (using codesign -f -i <> -s <> --options runtime --entitlements <list>) and now the extension loads successfully.


I was also wondering if I need to use 10.14SDK to compile the binaries and .dylibs, to fix this issue, but that doesn't seem be the case now.


Thanks.

Hi,


When I overwrite the old binaries with the newer one, I get "Killed: 9" error: Bad executable (or shared library)" when I execute any binary that has a dependecy on .dylib. The binaries that just depends on "/usr/lib/libSystem.B.dylib" works fine. When I reboot the machine, then all the binaries work fine and no error is seen.


Do I need to flush dylib cache or any other cache to avoid the reboot? Or How can I fix it please?


Thank you.

When I reboot the machine, then all the binaries work fine and no error is seen.

Right. That’s a classic symptom of a code signing oddity in Apple systems where the kernel caches information about the signature and doesn’t flush that cache when you rewrite the Mach-O image file. The solution is to not rewrite the image file, but instead create a new image file and move it into place.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Could you please eleborate? We create postgresql-12.2-1-osx.dmg and postgresql-12.2-1-osx.zip that includes the .app bundle. When you install the app bundle it will extract the executables, .so's and dependent .dylib's


Since we codeisgn each binary and .so, I made a change to add --entitlements and rebuilt a new version of DMG (postgresql-12.2-2-osx.dmg). Now, when I install this new DMG which overwrites executables and .so's.

Now, when I install this new DMG which overwrites executables and

.so
s.

It depends on how you do the installation. There are two basic strategies for installing a new file:

  • Create a new file, copy the content you want to that file, close it, move the new file into the location you want it (A).

  • Open the existing file, copy the content you want to that file, close it (B).

Option B is generally a bad idea (because its not atomic) but, in the specific case of Mach-O executables, it will cause problems. Use option A.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I believe installer upgrades follow Option A. Because the new installer (DMG) carries the new builds and get overwritten in the same location where the older files exist on disk. But, let me confirm from the Bitrock team and get back.

I believe installer upgrades follow Option A.

You should be able to confirm that using

fs_usage
.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

yes, you were right. That was the problem. The installer tool fixed the issue and now after the upgrade installation is done, the binaries work fine. Thanks so much for explaining the problem.

That’s a classic symptom of a code signing oddity in Apple systems where the kernel caches information about the signature and doesn’t flush that cache when you rewrite the Mach-O image file.

I finally got around to writing this up officially, in Updating Mac Software.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"