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

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

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"