kIOReturnNotPermitted from IOHIDManagerOpen under lldb

I'm writing a C/C++ command line program which, at some point, calls IOHIDManagerOpen. I've added both my program executable and lldb as permitted for input monitoring (as far as I remember, my program was added after showing up a permission prompt, I've added lldb manually later, trying to resolve the problem).

My problem is that when I run my program from within lldb in Terminal, the call to IOHIDManagerOpen returns kIOReturnNotPermitted. When I run my program directly in the terminal session (without lldb), this call returns kIOReturnSuccess. Such behaviour means it will be impractical to use lldb for any debugging of this program.

What can be done to make lldb session behave the same way, the normal execution works?

I'm on: 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64 and: lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

Replies

TCC is primarily focused on apps, so you’ll see a variety of odd behaviours when you bump into it in a non-app context, such as a command-line tool. When a process hits a restriction, TCC needs to determine the responsible code, which isn’t always easy. I talk about this a little in my On File System Permissions post.

The best way to fix this depends on what sort of program you’re building:

  • Are you writing this code in a command-line tool because it’s convenient? Or do you plan to ship that?

  • If you plan to ship it, will it be something that the user runs directly from Terminal? Or a tool that you plan to embed in a GUI app? Or something else?

Share and Enjoy

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

  • this exists as command-line tool for development purpose only, to interact with the code that will ultimately become part of launch agent which will expose some form of IPC to application which will bundle it. So I'm up for any hack that allows me to make my command line tool work in debugger for now even though it might not be appropriate as general approach.

Add a Comment