Looking for code-signing a python script on macOS Sonoma 14.0 to be able to debug with gdb and lldb

Question

on macOS Sonoma 14.0, I have a python script that i launch with Intel OneAPI framework.

At the execution with Intel's python3.9 ( 2022.2.0), it generates a segmetation error after doing some omputations.

I would like to get the backtrace of this ssegfault on macOS.

I tried to use "gdb" "lldb" but impossible to use them sice it is said that the files are not codesigned.

For example, with gdb, I get :

$ gdb -ex run --args python3.9 camb_and_hi_classy_fails.py

and after typing "run", I get this error :

gdb -exe run --args python3.9 camb_and_hi_classy_fails.py
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin22.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3.9...
(No debugging symbols found in python3.9)
(gdb) r
Starting program: /opt/intel/oneapi/intelpython/python3.9/bin/python3.9 camb_and_hi_classy_fails.py
Unable to find Mach task port for process-id 16678: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)

AND with lldb, I get also the same kind of error :

lldb --file python3.9 camb_and_hi_classy_fails.py
(lldb) target create "/opt/intel/oneapi/intelpython/latest/bin/python3.9"
Current executable set to '/opt/intel/oneapi/intelpython/latest/bin/python3.9' (x86_64).
(lldb) settings set -- target.run-args  "camb_and_hi_classy.py"
(lldb) r
error: process exited with status -1 (attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
(lldb)

I have followed the instructions from the first answer on :

What are the ways or technologies to sign an executable application file in mac os x environment?

that is to say, I did :

First you will need to generate your own certificate.

open -a "Keychain Access"
(MENU) Certificate Assistant  Create a Certificate
Enter the Name (for example my-codesign-cert)
Identity Type  Self Signed Root
Certificate Type Code Signing
Check "Let me override defaults" & click Continue.
Enter a unique Serial Number.
Enter a big Validity Period (days), like 3560 & click Continue.
Fill in your personal information & click Continue.
Accept defaults for the rest of the dialog boxes.

and Codesign your items :

codesign -s my-codesign-cert path_to_my_binary_executable

Then I did (tried both for user and root) :

1. $ codesign -s my-codesign-cert camb_and_hi_classy_fails.py

2. Did the same for Python3.9 :

   $ codesign -s my-codesign-cert /opt/intel/oneapi/intepython/last/bin/python3.9
   

But I can't still use gdb or lldb on my Mac.

I tried to follow the instrusctions on this link :

What are the ways or technologies to sign an executable application file in mac os x environment?

Answer 1

The gdb error is a bit of a red herring. gdb won't work at all if it isn't properly code signed, so it's offering that as its best guess when an attach fails.

LLDB's error is closer:

attach failed (Not allowed to attach to process

The system prevented you from debugging the binary you were trying to debug. The various agents that deny debugging are cordoned off from lldb, so we can't tell you exactly why this was denied. But in this case, the thing you are actually not being allowed to attach to is the python binary.

When you run script with #!/usr/bin/python the shell re-exec's that to python scriptname so the actual binary is some variant of python. In your case, that's the Xcode install of Python, and that isn't marked to be debuggable. As a security measure, macOS by default does not allow users to debug any binary that isn't built with explicit permission to allow debugging, so you were denied.

You can work around this by building your own Python binary and debugging that (not particularly hard to do and then you have symbols for Python as well...); or by enabling SIP w/o the debugging protections. To do the latter, follow the instructions here:

https://developer.apple.com/documentation/security/disabling_and_enabling_system_integrity_protection

but instead of running csrutil disable following this note:

https://developer.apple.com/forums/thread/17452

run csrutil enable --without debug. That will allow you to debug system binaries while leaving on the other SIP protections.