Score:1

Open serial port without root priviledges on Ubuntu (udev rules)

um flag

I was following this tutorial to setup access to Flir Boson camera serial port from userspace:

https://www.forecr.io/blogs/connectivity/how-to-integrate-flir-boson-thermal-camera-to-nvidia-jetson-modules

The camera installs as /dev/ttyACM0 and in the tutorial there's a .rules file you're supposed to download and copy to: /etc/udev/rules.d/. And then reboot.

This is the content of the file:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="09cb", OWNER="nvidia", MODE="0777", GROUP="nvidia"

But it does not work for me. Even after reboot, my application still requires sudo to be able to communicate with the camera.

Now it seems to me, that the tutorial assumes you have a certain username, in this case possibly "nvidia". So I also tried to change OWNER to my actual username, but that does not help either.

A part of the problem may be that I don't really understand what OWNER and GROUP fields are exactly for, I am only guessing. Of course I have been trying to Google that, but for some reason, I am obviously not able to phrase the query correctly.

This is nVidia Jetson Xavier NX with JetpackSDK 4.6, which is in fact Ubuntu 18.04.

Thanks!

ru flag
The 'Owner" and "Group" items are to determine the user on-system that owns the device. You are not able to access the camera, yes? Without the `udev` rules in place, reboot and connect the camera. What does `ls -al /dev/ttyACM0` show? This will help us ID the groups to add your user to in order to access the device.
um flag
Hi, it will print out the following: `crw-rw---- 1 root dialout 166, 0 pro 2 17:58 /dev/ttyACM0` Also I am not sure what exactly do you mean by the question if I am able to access the camera. The camera feed works well, but that's not what ttyACM0 is for. It is a serial port that can be used to send some control comands, like changing color modes, brightness, autofocus interval and things like that.
ru flag
it doesn't matter what it is, what matters is that 'dialout' group. And it's very easy to add yourself to that group.
Score:1
ru flag

Your rules file alters the user and group to the nonexistent user and group nvidia - this is not going to solve your problem in fact it'll just not work because the user and group nvidia isn't a default group, and your user isn't in it. You also shouldn't set your sockets to 777 permissions - for the same reason you don't give it to files (see this post regarding why you shouldn't give 777 to /var/www for similar security concerns). There are additional access controls to devices as part of AppArmor isolation rules for different applications as well, which you can't overcome as a standard user. Which is why the dialout group exists to give access to those devices.

The nVidia tutorial is likely for some other system, or outdated - you shouldn't need to use their rules, instead just give yourself access with dialout.

When working with user level privileges, special devices such as serial port communications require extra privileges. These are granted by the dialout group (for devices such as dialup modems, USB Serial Adapters, etc.)

Simply add your group to the dialout group, reboot, and you'll have access. Use this command on the command line:

sudo usermod -a -G dialout $USER

Replace $USER with your username on the computer, then when you reboot and relogon to your session you'll have access to that device and other devices. Serial communication ports require dialout permissions, which is easy to put yourself into.

That should be all you or any other user needs to do to access the device. You should leave the default permissions alone, unless you have some very specific use case that is not specified in your question.

um flag
This indeed solved the problem. I tried this even before writing here, but the problem was that with combination with that `.rules` file, it wouldn't work. Any explanation for that? Why did that tutorial bothered with those `.rules` anyway?
ru flag
@Aros the Rules file dictates alternative rules for setting up file permissions on devices. By adding the rules, you changed the user and group to `nvidia` which (1) isn't a default group and (2) your user isn't in. The user and group have to be the user and group which has *access* to the device. Default permissions are read/write for the device socket file for owner and group of the representative file - you could make it your user and group, or simply leave the defaults and give yourself dialout. If you use a rules file, it *changes* the defaults.
ru flag
Which is *why* I asked you to `ls` without the rules file, because you don't *need* to alter the permissions on the represesntative device file - you simply need to give yourself access permissions. Same for any other user on the system even if it's a system user. You should only **in extremely extremely rare cases** have to have a custom rule.
um flag
Brilliant. Thanks you!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.