20

This question might not be specific to the raspberry pi, of course. Also, I'm relatively new to Linux.

I want to write a little library (in node.js, if that matters) to access the GPIO of the raspberry pi using the sysfs. However, accessing the sysfs requires sudo access, and that's bad for obvious reasons.

Quick2Wire seems to have a solution, but I want to understand it better and not just blindly use it. They've used C of course, but from what I understand, the code isn't complex, and probably can be pulled off with just bash, even if less elegantly. However, more than anything, I'm not sure why it works.

Any help will be great.

Edit: Thanks for the comments. It's clear I need to rephrase the question. Here goes: How is it that once installed (as root), the app doesn't require any more root perms to use? How does adding someone to a group help in this case? /sys/devices/virtual/gpio isn't the location where the gpio sysfs is available, so what's the trickery with that? I'm really a n00b, so these questions might be n00b-ish, so please bear with me.

Rakesh Pai
  • 26,069
  • 3
  • 25
  • 31
  • So what is the question ? Do you want it translated in bash ? – cnicutar Aug 26 '12 at 21:08
  • Sorry for the lack of clarity in the question. I've added an edit. Hope that clarifies the question. – Rakesh Pai Aug 26 '12 at 21:15
  • @cnicutar Don't want it translated per se. I understand bash better than C (though the C code there isn't complex at all). I just think that a bash script will be easier to understand than C, considering my C knowledge. Given that this code (along with the makefile) seems to be doing some trickery that I don't understand, a bash script might explain at least the important parts better for me. This isn't a "give me teh codez" question. It's more of a "why does this work" question. – Rakesh Pai Aug 26 '12 at 21:23
  • @RakeshPai Where are the required files available ? I.e. at what absolute path. – cnicutar Aug 26 '12 at 21:36
  • @cnicutar the native/original sysfs? That's at ``/sys/class/gpio``. Related: I'm reasonably convinced that my question has nothing to do with the GPIO or with the raspberry-pi. I think it's just about users, groups, permissions, and how it all works given that something wants sudo but you don't want to expose that. Thanks for helping so far. – Rakesh Pai Aug 26 '12 at 22:05
  • @RakeshPai Are you sure the files aren't symlinks ? – cnicutar Aug 26 '12 at 22:22
  • The Makefile at https://github.com/quick2wire/quick2wire-gpio-admin/blob/master/Makefile doesn't seem to create any symlinks, nor does the C code. The ``/sys/class/gpio`` sysfs doesn't seem to be synlinks from a ``ls -la`` output. In any case, could symlinks help in this regard? My not-so-honed knowledge tells me that just symlinking wouldn't help solve root-related problems, but I might be wrong. – Rakesh Pai Aug 26 '12 at 22:28
  • @rakesh pai. You are right, ideally udev rules should be able to set the permissions. I spent a couple of hours the other night trying to get used to set the permissions and just couldn't do it. It seems a lot of people have tried and also cannot get it to work. At the moment you have two choices, on bootup run a script that sets the permissions explicitly or use sudo. – Tim Hoffman Aug 31 '12 at 23:45

1 Answers1

21

Rakesh, I've just been trying to figure out exactly the same thing, and I think I've solved it.

You don't need to understand much of the makefile at all. The important lines are the following, which are executed in bash when you run sudo make install

install: install-files
    groupadd -f --system gpio
    chgrp gpio $(DESTDIR)/bin/gpio-admin
    chmod u=rwxs,g=rx,o= $(DESTDIR)/bin/gpio-admin

groupadd -f --system gpio creates a system group called gpio. chgrp gpio $(DESTDIR)/bin/gpio-admin changes the group of the binary (which the C file gpio-admin.c was compiled to) to gpio. The owner of the binary is still root (since you're running make as root.) chmod u=rwxs,g=rx,o= $(DESTDIR)/bin/gpio-admin does two important things. Firstly, it lets a member of the gpio group run gpio-admin. Secondly, it sets the setuid bit on gpio-admin.

When you add yourself to the gpio group, you can run gpio-admin, without using sudo, but gpio admin will act like it is being run under sudo. This allows it to write to the /sys/class/gpio/export file. It also allows it to change the owner of the files /sys/class/gpio/gpio[pin number]/direction etc. that get created.

Even if you change the group of /sys/class/gpio/export to gpio, and set permissions to allow you to write to it

sudo chgrp gpio /sys/class/gpio/export /sys/class/gpio/unexport
sudo chmod g+rwx /sys/class/gpio/export /sys/class/gpio/unexport

you can export a pin without superuser powers

echo 22 > /sys/class/gpio/export

but the files /sys/class/gpio/gpio22/direction etc. will still be create with root as the owner and group, and you'll need to use sudo to change them. Also, ownership of the export and unexport files will revert to root after each reboot.

pylover
  • 7,670
  • 8
  • 51
  • 73
Harry Braviner
  • 627
  • 4
  • 12
  • 1
    Thanks Harry. This helps a lot. Could you also figure out what's the deal with the /sys/devices/virtual/gpio path, where ``virtual" doesn't exist by default? – Rakesh Pai Sep 14 '12 at 07:33