how to attach lldb to python installed with python.org installer on OSX
Question:
System:
Intel MacBook Pro 16"
Mac OS 12.5
> lldb --version
lldb-1316.0.9.46
Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)
For a simple test case of:
# hello_world.py
print("hello world")
Using python 3.10.6 installed from the python.org website, when I try to attach lldb to it, I get the following error:
> lldb python3 hello_world.py
(lldb) target create "python3"
Current executable set to 'python3' (x86_64).
(lldb) settings set -- target.run-args "hello_world.py"
(lldb) run
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)
Adding sudo to the lldb call does not help, and I’m not having any luck finding something in the Console app, though maybe I’m looking in the wrong place.
However, when I run under a conda environment installed in ~/miniconda3/envs/someenv
then it works just fine:
> lldb python3 hello_world.py
(lldb) target create "python3"
Current executable set to 'python3' (x86_64).
(lldb) settings set -- target.run-args "hello_world.py"
(lldb) run
Process 24402 launched: '/Users/vince/miniconda3/envs/py39/bin/python3' (x86_64)
hello world
Process 24402 exited with status = 0 (0x00000000)
(lldb)
Looking for what I have to do to get it working with the installer installed python if possible.
Answers:
The reason you can’t run lldb against the Python 3.10 you downloaded from python.org is that it’s a hardened binary, which is supposed to make applications more secure by default-denying things that could do the kinds of things a debugger could do.
You can see for yourself by running the command…
codesign -d -v --entitlements - $(which python3)
Here’s mine (on an exploded version of the pkg installer from python’s site:
codesign -d -v --entitlements - ${HOME}/python-3.10.6/Python_Framework.pkg/Versions/3.10/bin/python3.10
Executable=/Users/wkl/python-3.10.6/Python_Framework.pkg/Versions/3.10/bin/python3.10
Identifier=python3
Format=Mach-O universal (x86_64 arm64)
# flags=0x10000(runtime) indicates the binary is hardened
CodeDirectory v=20500 size=755 flags=0x10000(runtime) hashes=13+7
location=embedded
Signature size=8998
Timestamp=Aug 1, 2022 at 17:21:35
Info.plist=not bound
TeamIdentifier=DJ3H93M7VJ
Runtime Version=12.1.0
Sealed Resources=none
Internal requirements count=1 size=168
[Dict]
[Key] com.apple.security.automation.apple-events
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-dyld-environment-variables
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-executable-page-protection
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-library-validation
[Value]
[Bool] true
And the official Python installer needs to be built with hardened runtime enabled because it’s necessary to pass Apple notarization – this is also described in their own build docs:
To pass macos Gatekeeper download quarantine, the final package must
be signed with a valid Apple Developer ID certificate using
productsign.
Starting with macOS 10.15 Catalina, Gatekeeper now also
requires that installer packages are submitted to and pass Apple’s
automated notarization service using the altool command.
To pass notarization, the binaries included in the package must be built with
at least the macOS 10.9 SDK, must now be signed with the codesign
utility, and executables must opt in to the hardened run time option
with any necessary entitlements.
All of the above is to say that it’s this way because of modern macos security restrictions.
One (temporary) potential solution is to disable SIP, as described in Apple’s own documentation, but understand that it carries security risks and isn’t recommended for normal usage.
Another is just to have your own builds of Python if you need specific versions that are otherwise unavailable, or use any install that isn’t the officially built packages.
System:
Intel MacBook Pro 16"
Mac OS 12.5
> lldb --version
lldb-1316.0.9.46
Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)
For a simple test case of:
# hello_world.py
print("hello world")
Using python 3.10.6 installed from the python.org website, when I try to attach lldb to it, I get the following error:
> lldb python3 hello_world.py
(lldb) target create "python3"
Current executable set to 'python3' (x86_64).
(lldb) settings set -- target.run-args "hello_world.py"
(lldb) run
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)
Adding sudo to the lldb call does not help, and I’m not having any luck finding something in the Console app, though maybe I’m looking in the wrong place.
However, when I run under a conda environment installed in ~/miniconda3/envs/someenv
then it works just fine:
> lldb python3 hello_world.py
(lldb) target create "python3"
Current executable set to 'python3' (x86_64).
(lldb) settings set -- target.run-args "hello_world.py"
(lldb) run
Process 24402 launched: '/Users/vince/miniconda3/envs/py39/bin/python3' (x86_64)
hello world
Process 24402 exited with status = 0 (0x00000000)
(lldb)
Looking for what I have to do to get it working with the installer installed python if possible.
The reason you can’t run lldb against the Python 3.10 you downloaded from python.org is that it’s a hardened binary, which is supposed to make applications more secure by default-denying things that could do the kinds of things a debugger could do.
You can see for yourself by running the command…
codesign -d -v --entitlements - $(which python3)
Here’s mine (on an exploded version of the pkg installer from python’s site:
codesign -d -v --entitlements - ${HOME}/python-3.10.6/Python_Framework.pkg/Versions/3.10/bin/python3.10
Executable=/Users/wkl/python-3.10.6/Python_Framework.pkg/Versions/3.10/bin/python3.10
Identifier=python3
Format=Mach-O universal (x86_64 arm64)
# flags=0x10000(runtime) indicates the binary is hardened
CodeDirectory v=20500 size=755 flags=0x10000(runtime) hashes=13+7
location=embedded
Signature size=8998
Timestamp=Aug 1, 2022 at 17:21:35
Info.plist=not bound
TeamIdentifier=DJ3H93M7VJ
Runtime Version=12.1.0
Sealed Resources=none
Internal requirements count=1 size=168
[Dict]
[Key] com.apple.security.automation.apple-events
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-dyld-environment-variables
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-executable-page-protection
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-library-validation
[Value]
[Bool] true
And the official Python installer needs to be built with hardened runtime enabled because it’s necessary to pass Apple notarization – this is also described in their own build docs:
To pass macos Gatekeeper download quarantine, the final package must
be signed with a valid Apple Developer ID certificate using
productsign.Starting with macOS 10.15 Catalina, Gatekeeper now also
requires that installer packages are submitted to and pass Apple’s
automated notarization service using the altool command.To pass notarization, the binaries included in the package must be built with
at least the macOS 10.9 SDK, must now be signed with the codesign
utility, and executables must opt in to the hardened run time option
with any necessary entitlements.
All of the above is to say that it’s this way because of modern macos security restrictions.
One (temporary) potential solution is to disable SIP, as described in Apple’s own documentation, but understand that it carries security risks and isn’t recommended for normal usage.
Another is just to have your own builds of Python if you need specific versions that are otherwise unavailable, or use any install that isn’t the officially built packages.