hidapi-libusb: hid_open fails when run with non-root access (*sometimes)

[treykazee]

Throwing this out there to see if anyone has seen something similar or has advice - thanks in advance!

I've used hidapi-libusb for a while with a custom USB device designed for software protection (ie, a license dongle). Recently a coworker re-worked our licensing module and now I consistently get hid_open failure unless I run my software with sudo privelege.

I've set up my udev rules. Curiously, I can run the hidtest-libusb without issue; in other words, hid_open succeeds without sudo privilege when running the test app. Initially, I wondered if it was related to our threading of usb access (which is new), but all of the usb access occurs in the same thread; also, I removed the threading to try and isolate what is happening and it seems to behave the same: in my software, hid_open fails unless I run with sudo privilege (but the test app works fine).

Has anyone seen a compiler/build option that could cause this to happen? At this point, I'm stumped as to why the test application succeeds in hid_open but my application does not.

[Youw]

My best guess - your SW isn't consistent with your udev rules.
Assuming the udev rule setups access to the device for a particular user/group - your SW either running under a different one, or changes uid/euid/gid/egid in run time.

Or you simply trying to open a wrong device.

---

In any case, I don't believe a compiler/build option exists that may cause such effect as you observe.

I may suggest inserting the code of the test app into your code in different place, e.g. try to execute the code of the test app inside your main before everything else, etc.

[treykazee]

Thank you for the quick reply!

I'm quite sure that I'm using the correct VID/PID - in fact, the class controlling access to this specific device hasn't changed and I have confirmed normal operation with v0.13.1 in my previous software architecture (I updated from 0.11.0). In other words, my old code works and the hidtest-libusb works - but my new build (the software was re-organized and threaded) only works when run with sudo priveleges. I believe the udev rules are ok - though in trying to figure out what is happening I've tried variations of TAG+="uaccess" and MODE="0666" .

I'll try your suggestion of executing the code in a different location to see if I can uncover what is happening. I'll also report back if I learn anything. Thanks!

[treykazee]

Follow up: I have identified a key clue.

1. In all cases, hid_enumerate (with my specific VID/PID) succeed.
2. In my old code and hidtest-libusb (both of which work as expected), the device path is indicated as "2-1:1.0"
3. In my new code (which only "works" when run with sudo privilege), the device path is indicated as "/dev/hidraw0"

I am linking explicitly with the static library (hidapi-libusb.a), so don't yet understand why the path is coming back differently. If I run hidtest-hidraw then the test behaves like my new code; however, since I am explicitly linking with hidapi-libusb I am suprised it comes back differently.

Are you aware of any reason the hidapi-libusb library would return a device path under /dev/hidraw0?

Many thanks!

[Youw]

I am linking explicitly with the static library (hidapi-libusb.a)

I suggest to double(or triple)-check this part.
If you're getting a device path as "/dev/hidraw0" - that is definitely hidapi-hidraw backend.

Maybe you're linking both libraries somehow and the linker (surprisingly) doesn't take it as an ODR violation, but instead optimizes one library out.

[Youw]

that is definitely hidapi-hidraw backend

You should be able to confirm that with a debugger/strace/ldd/etc.;

[treykazee]

Maybe you're linking both libraries somehow and the linker (surprisingly) doesn't take it as an ODR violation, but instead optimizes one library out.

I think you are correct. I understand now what is happening, and thank you very much for your help!

It looks like in the new module my coworker added support for an additional device which is built by another company; in doing so, he linked their device's API library. It seems that their API library defines all of the hid_* calls (hid_init, hid_enumerate, hid_open, etc) - so even though I thought I was explicitly linking against hidapi-libusb, the linker was resolving my hid_* calls using their library. I did not anticipate they included implementation of hid_* inside their library - I expected it only to provide their documented API calls.

In any case, I really appreciate such prompt responses to help narrow down what is happening.

[Youw]

Happy to help.