2

I'm using hidapi for accessing a HID device (which is not a mouse or a keyboard). The oldest OS version to be supported is 10.6, I'm currently using Mac OX X 10.6.8. If my Mac OS X executable is running with normal user rights it can enumerate the devices, identify the device to be used by it's vendor and product ID and open it like this:

IOHIDDeviceRef os_dev = ...
IOReturn ret = IOHIDDeviceOpen(os_dev, kIOHIDOptionsTypeNone);
if (ret == kIOReturnSuccess) { ... } // here I get kIOReturnNotPrivileged for daemon

Actually the executable should run as daemon, but then IOHIDDeviceOpen fails with kIOReturnNotPrivileged. For Linux I circumvented a similar problem with a hotplug script fire by an udev rule and thus changed the rights for the newly connected (matching) devices. I would like to stick to the daemon user. How can I achieve this?

ur.
  • 2,890
  • 1
  • 18
  • 21

3 Answers3

1

I've opened an Apple Developer Support Ticket and got some answers. The problem is not, that my application is running as user 'daemon'. At least, not exactly...

The application has to run as an authenticated (logged in interactive) user - or 'root'. So, if I could log on as 'daemon' it propably would run. Actually, this doesn't help. I need an (launchd) daemon, because the functionality of my application is kind of a server accessible over network. Therefore, I have to run the application as user 'root' - which is the dangerous default for lauchd daemons anyway.

ur.
  • 2,890
  • 1
  • 18
  • 21
1

If your app isn't sandboxed, you don't need any entitlements, so it sounds like that's not your problem. And whether the app is a daemon or not is also irrelevant.

What's relevant is whether the operating system considers your device to be a keyboard or not. To reduce the risk of keylogger abuse, OS X requires that any app that wants to talk directly to a keyboard must run as root. Unfortunately, lots of non-keyboard HID devices present themselves as keyboards (e.g. wireless presenter remotes). That's probably what you're seeing.

You can either fix that by running as root or, if you're in control over the hardware itself, by changing its usage page value to something other than 7 (keyboards).

dgatwood
  • 10,129
  • 1
  • 28
  • 49
0

IIRC Lion kicked the necessary priv's up a notch… now you'll need a sandboxing entitlement; probably "com.apple.security.device.usb".

geowar
  • 4,397
  • 1
  • 28
  • 24
  • Thank you for your answer, but I develop for OS X, not for iOS. – ur. Dec 20 '12 at 10:39
  • Lion is Mac OS X 10.7; Mountain Lion is Mac OS X 10.8… didn't say anything about iOS. – geowar Dec 21 '12 at 02:54
  • I'm sorry I was to quick. Your link was about iOS. And I have to add to my question that the problem also occurs with Mac OX X 10.6.8. I will investigate in this topic after Chrismas. Thank you again. – ur. Dec 21 '12 at 09:38
  • Ok, I've updated the URL to point to the Mac OSX sandboxing entitlements page. – geowar Dec 21 '12 at 16:30