How do I make libusb work as non-root?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







2















I'm making a custom USB HID device, and a desktop app to go with it, using HIDAPI on Lubuntu 16.04.3 LTS. We'll call it myapp for now.



Apparently, if I do $ ./myapp, libusb_open() fails with LIBUSB_ERROR_ACCESS. (shown in my debugger as -3; it took a while to figure that out because the enum doesn't seem to be documented very well)

But if I do $ sudo ./myapp, it succeeds.

I really don't want myapp to have root permissions, so how can I talk to my USB device without them?





I was hoping for an answer here, but it seems to have been abandoned at exactly this point. It says something about user permissions, but I can't seem to find that on my system. I thought I might find a group called usb or libusb that I could add myself to, but no such luck.





This question on a different SE site has an answer that uses some austere text files to change the permissions either globally (probably a bad idea) or for a specific device, but:




  1. It's not the "muggle's tweak" that I was looking for.

  2. Most of those files have a warning against modifying directly because they're auto-generated. So how can I be sure that a random package update isn't going to wipe out my changes and thus break myapp?

  3. It doesn't seem to do anything anyway. I followed those instructions and rebooted, and myapp with user permissions still can't talk to USB.










share|improve this question




















  • 1





    unix.stackexchange.com/questions/44308/…

    – Rinzwind
    Nov 20 '17 at 21:39











  • @Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

    – AaronD
    Nov 26 '17 at 0:32


















2















I'm making a custom USB HID device, and a desktop app to go with it, using HIDAPI on Lubuntu 16.04.3 LTS. We'll call it myapp for now.



Apparently, if I do $ ./myapp, libusb_open() fails with LIBUSB_ERROR_ACCESS. (shown in my debugger as -3; it took a while to figure that out because the enum doesn't seem to be documented very well)

But if I do $ sudo ./myapp, it succeeds.

I really don't want myapp to have root permissions, so how can I talk to my USB device without them?





I was hoping for an answer here, but it seems to have been abandoned at exactly this point. It says something about user permissions, but I can't seem to find that on my system. I thought I might find a group called usb or libusb that I could add myself to, but no such luck.





This question on a different SE site has an answer that uses some austere text files to change the permissions either globally (probably a bad idea) or for a specific device, but:




  1. It's not the "muggle's tweak" that I was looking for.

  2. Most of those files have a warning against modifying directly because they're auto-generated. So how can I be sure that a random package update isn't going to wipe out my changes and thus break myapp?

  3. It doesn't seem to do anything anyway. I followed those instructions and rebooted, and myapp with user permissions still can't talk to USB.










share|improve this question




















  • 1





    unix.stackexchange.com/questions/44308/…

    – Rinzwind
    Nov 20 '17 at 21:39











  • @Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

    – AaronD
    Nov 26 '17 at 0:32














2












2








2


1






I'm making a custom USB HID device, and a desktop app to go with it, using HIDAPI on Lubuntu 16.04.3 LTS. We'll call it myapp for now.



Apparently, if I do $ ./myapp, libusb_open() fails with LIBUSB_ERROR_ACCESS. (shown in my debugger as -3; it took a while to figure that out because the enum doesn't seem to be documented very well)

But if I do $ sudo ./myapp, it succeeds.

I really don't want myapp to have root permissions, so how can I talk to my USB device without them?





I was hoping for an answer here, but it seems to have been abandoned at exactly this point. It says something about user permissions, but I can't seem to find that on my system. I thought I might find a group called usb or libusb that I could add myself to, but no such luck.





This question on a different SE site has an answer that uses some austere text files to change the permissions either globally (probably a bad idea) or for a specific device, but:




  1. It's not the "muggle's tweak" that I was looking for.

  2. Most of those files have a warning against modifying directly because they're auto-generated. So how can I be sure that a random package update isn't going to wipe out my changes and thus break myapp?

  3. It doesn't seem to do anything anyway. I followed those instructions and rebooted, and myapp with user permissions still can't talk to USB.










share|improve this question
















I'm making a custom USB HID device, and a desktop app to go with it, using HIDAPI on Lubuntu 16.04.3 LTS. We'll call it myapp for now.



Apparently, if I do $ ./myapp, libusb_open() fails with LIBUSB_ERROR_ACCESS. (shown in my debugger as -3; it took a while to figure that out because the enum doesn't seem to be documented very well)

But if I do $ sudo ./myapp, it succeeds.

I really don't want myapp to have root permissions, so how can I talk to my USB device without them?





I was hoping for an answer here, but it seems to have been abandoned at exactly this point. It says something about user permissions, but I can't seem to find that on my system. I thought I might find a group called usb or libusb that I could add myself to, but no such luck.





This question on a different SE site has an answer that uses some austere text files to change the permissions either globally (probably a bad idea) or for a specific device, but:




  1. It's not the "muggle's tweak" that I was looking for.

  2. Most of those files have a warning against modifying directly because they're auto-generated. So how can I be sure that a random package update isn't going to wipe out my changes and thus break myapp?

  3. It doesn't seem to do anything anyway. I followed those instructions and rebooted, and myapp with user permissions still can't talk to USB.







usb permissions






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 2 at 15:39









Dagelf

29648




29648










asked Nov 20 '17 at 21:29









AaronDAaronD

236413




236413








  • 1





    unix.stackexchange.com/questions/44308/…

    – Rinzwind
    Nov 20 '17 at 21:39











  • @Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

    – AaronD
    Nov 26 '17 at 0:32














  • 1





    unix.stackexchange.com/questions/44308/…

    – Rinzwind
    Nov 20 '17 at 21:39











  • @Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

    – AaronD
    Nov 26 '17 at 0:32








1




1





unix.stackexchange.com/questions/44308/…

– Rinzwind
Nov 20 '17 at 21:39





unix.stackexchange.com/questions/44308/…

– Rinzwind
Nov 20 '17 at 21:39













@Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

– AaronD
Nov 26 '17 at 0:32





@Rinzwind I finally got some time during Thanksgiving gatherings to test that. It does absolutely nothing on my system. See edit.

– AaronD
Nov 26 '17 at 0:32










1 Answer
1






active

oldest

votes


















4














It's still not the "muggle's tweak" that I'm really looking for, but at least this works:



Apparently there are two directories for udev (I have no idea why):




  • /etc/udev/rules.d

  • /lib/udev/rules.d


I'd been messing with the /lib one and getting nowhere. I found the /etc one here, and it does work:





Put SUBSYSTEM=="usb", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", MODE="0666"





  • VID is the USB-IF-assigned Vendor ID of the device in question *


  • PID is the Vendor-assigned Product ID of the device in question *


  • 0666 gives universal read/write access to whatever matches this line



    * $ lsusb to see all attached USB devices and their ID's.




In /etc/udev/rules.d/xx-my-rule.rules (may need root/sudo permissions)





  • xx is any number > 50 (the defaults are in 50, and higher numbers take priority)


  • my-rule is whatever you want to call it

  • must end in .rules


Then udevadm control --reload-rules (may also need root/sudo permissions), and it should "just work" for that specific VID/PID pair.





Another option, to tighten the permissions a little bit more, is to use TAG+="uaccess" in place of MODE="0666". This limits access to the currently-logged-in (physical) user instead of all users. Thanks @Lekensteyn!






share|improve this answer





















  • 1





    As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

    – Lekensteyn
    Nov 27 '17 at 23:52













  • That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

    – AaronD
    Nov 28 '17 at 0:03












Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f978552%2fhow-do-i-make-libusb-work-as-non-root%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














It's still not the "muggle's tweak" that I'm really looking for, but at least this works:



Apparently there are two directories for udev (I have no idea why):




  • /etc/udev/rules.d

  • /lib/udev/rules.d


I'd been messing with the /lib one and getting nowhere. I found the /etc one here, and it does work:





Put SUBSYSTEM=="usb", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", MODE="0666"





  • VID is the USB-IF-assigned Vendor ID of the device in question *


  • PID is the Vendor-assigned Product ID of the device in question *


  • 0666 gives universal read/write access to whatever matches this line



    * $ lsusb to see all attached USB devices and their ID's.




In /etc/udev/rules.d/xx-my-rule.rules (may need root/sudo permissions)





  • xx is any number > 50 (the defaults are in 50, and higher numbers take priority)


  • my-rule is whatever you want to call it

  • must end in .rules


Then udevadm control --reload-rules (may also need root/sudo permissions), and it should "just work" for that specific VID/PID pair.





Another option, to tighten the permissions a little bit more, is to use TAG+="uaccess" in place of MODE="0666". This limits access to the currently-logged-in (physical) user instead of all users. Thanks @Lekensteyn!






share|improve this answer





















  • 1





    As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

    – Lekensteyn
    Nov 27 '17 at 23:52













  • That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

    – AaronD
    Nov 28 '17 at 0:03
















4














It's still not the "muggle's tweak" that I'm really looking for, but at least this works:



Apparently there are two directories for udev (I have no idea why):




  • /etc/udev/rules.d

  • /lib/udev/rules.d


I'd been messing with the /lib one and getting nowhere. I found the /etc one here, and it does work:





Put SUBSYSTEM=="usb", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", MODE="0666"





  • VID is the USB-IF-assigned Vendor ID of the device in question *


  • PID is the Vendor-assigned Product ID of the device in question *


  • 0666 gives universal read/write access to whatever matches this line



    * $ lsusb to see all attached USB devices and their ID's.




In /etc/udev/rules.d/xx-my-rule.rules (may need root/sudo permissions)





  • xx is any number > 50 (the defaults are in 50, and higher numbers take priority)


  • my-rule is whatever you want to call it

  • must end in .rules


Then udevadm control --reload-rules (may also need root/sudo permissions), and it should "just work" for that specific VID/PID pair.





Another option, to tighten the permissions a little bit more, is to use TAG+="uaccess" in place of MODE="0666". This limits access to the currently-logged-in (physical) user instead of all users. Thanks @Lekensteyn!






share|improve this answer





















  • 1





    As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

    – Lekensteyn
    Nov 27 '17 at 23:52













  • That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

    – AaronD
    Nov 28 '17 at 0:03














4












4








4







It's still not the "muggle's tweak" that I'm really looking for, but at least this works:



Apparently there are two directories for udev (I have no idea why):




  • /etc/udev/rules.d

  • /lib/udev/rules.d


I'd been messing with the /lib one and getting nowhere. I found the /etc one here, and it does work:





Put SUBSYSTEM=="usb", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", MODE="0666"





  • VID is the USB-IF-assigned Vendor ID of the device in question *


  • PID is the Vendor-assigned Product ID of the device in question *


  • 0666 gives universal read/write access to whatever matches this line



    * $ lsusb to see all attached USB devices and their ID's.




In /etc/udev/rules.d/xx-my-rule.rules (may need root/sudo permissions)





  • xx is any number > 50 (the defaults are in 50, and higher numbers take priority)


  • my-rule is whatever you want to call it

  • must end in .rules


Then udevadm control --reload-rules (may also need root/sudo permissions), and it should "just work" for that specific VID/PID pair.





Another option, to tighten the permissions a little bit more, is to use TAG+="uaccess" in place of MODE="0666". This limits access to the currently-logged-in (physical) user instead of all users. Thanks @Lekensteyn!






share|improve this answer















It's still not the "muggle's tweak" that I'm really looking for, but at least this works:



Apparently there are two directories for udev (I have no idea why):




  • /etc/udev/rules.d

  • /lib/udev/rules.d


I'd been messing with the /lib one and getting nowhere. I found the /etc one here, and it does work:





Put SUBSYSTEM=="usb", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", MODE="0666"





  • VID is the USB-IF-assigned Vendor ID of the device in question *


  • PID is the Vendor-assigned Product ID of the device in question *


  • 0666 gives universal read/write access to whatever matches this line



    * $ lsusb to see all attached USB devices and their ID's.




In /etc/udev/rules.d/xx-my-rule.rules (may need root/sudo permissions)





  • xx is any number > 50 (the defaults are in 50, and higher numbers take priority)


  • my-rule is whatever you want to call it

  • must end in .rules


Then udevadm control --reload-rules (may also need root/sudo permissions), and it should "just work" for that specific VID/PID pair.





Another option, to tighten the permissions a little bit more, is to use TAG+="uaccess" in place of MODE="0666". This limits access to the currently-logged-in (physical) user instead of all users. Thanks @Lekensteyn!







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 28 '17 at 0:08

























answered Nov 27 '17 at 23:35









AaronDAaronD

236413




236413








  • 1





    As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

    – Lekensteyn
    Nov 27 '17 at 23:52













  • That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

    – AaronD
    Nov 28 '17 at 0:03














  • 1





    As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

    – Lekensteyn
    Nov 27 '17 at 23:52













  • That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

    – AaronD
    Nov 28 '17 at 0:03








1




1





As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

– Lekensteyn
Nov 27 '17 at 23:52







As an alternative to the overly permissive MODE="0666", consider using TAG+="uaccess" as used here. It does not allow any local user to access the USB device, just the person who is logged in (physically). There is no need for udevadm control --reload-rules, it is read automatically. You just have to remove/reinsert the USB device after creating/changing that file.

– Lekensteyn
Nov 27 '17 at 23:52















That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

– AaronD
Nov 28 '17 at 0:03





That works too. Changed the file, ran the possibly unnecessary update command, rebooted (rather do all that than get frustrated for hours because I didn't tell it to update; some things do need that), and it still works. Thanks!

– AaronD
Nov 28 '17 at 0:03


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f978552%2fhow-do-i-make-libusb-work-as-non-root%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Category:香港粉麵

List *all* the tuples!

Channel [V]