Beaglebone black GPIO permissions

Beaglebone black GPIO permissions

File permissions for various pseudo file system objects can sometimes be a pain to get around. In this guide I hope to help others to work this problem by working with the system. Rather than against it. With that said, the GPIO pseudo file system structure is a protected directory / file structure for a good reason. Meaning, when you use this structure to communicate with the outside world. You had better know what you’re doing. Consider yourself warned.

Additionally, anyone can probably debate from many different angles as to whether this is a security hazard or not. Myself, I could probably argue from both sides of the fence. But the truth is, we need, or want GPIO access. What does it matter if we run as root, run our commands with sudo, or add ourselves to a group that has access rights to the necessary file(s) ? Actually, in my own mind there is a huge difference, but I’ll let you the reader make your own decisions. In this guide however, I’ll be demonstrating to the reader how to use groups for this purpose.

First, we need to create a group. As we can attempt to add ourselves to a group, or change access of a file or directory to a group. But if that group does not exist in the system. It is all for nothing.

Then of course, we should also add our regular user to this group. Otherwise what would be the point ?

Now, things can get a little tricky. We need to create a udev rule in order to change the /sys/class/gpio path from root:root access, to root:gpio( our target group ) access. To make things even more complicated. When we export a gpio pin, this creates a new file path( structure ) that also has root:root access rights by default. As if that were not enough of a “problem”. Things get even more complex in that we have 4 GPIO banks to contend with and no idea which GPIO may need to be exported and when.

The first problem is not really a problem at all. We simply chown, and chmod, recursively, the /sys/class/gpio path. The second, and third problems are actually much easier to deal with simultaneously than one might expect. In short we need to chown, and chmod recursively /sys/devices/platform/ocp/4????000.gpio/gpio/. ? Is a wildcard match for any single character. So with this in mind this should match all 4 GPIO bank paths. So when a pin for any gpio bank is exported. We should have group access rights.

After this we need to reboot in order for the changes to take place.

Then, once we’re logged back in we can experiment.

Great, now we’re ready to use GPIO pins in an application run by a regular user. If you need more information on how to use the sysfs GPIO file structure. Feel free to search the web for that information. There are many very good blog posts covering that material. Also, what I covered in this guide here just barely scratches the surface of what is possible. For instance, do you think it is possible to only enable a single GPIO pin, or a group of GPIO pins for use by your regular user with root permissions ? Let’s find out together, shall we ?

Now we *could* reload the udev rules without a reboot if we wanted to.

However, I want to reboot my Beaglebone so I know this works from a fresh boot. After a reboot . . .

Everything looks normal here. Let’s try to do the same with a different pin.

So we’re still able to export other pins, but we’re not able to set specific pin properties without using root permissions. Interesting . . . I’m not quite sure how one could keep from exporting pins other than those intended. But off the top of my head I would say it is probably possible with some crazy regex filter . . . Anyway, that is all for now, and I hope you learned something. I certainly did. Happy Beagling !!!

Beaglebone black GPIO permissions