C Code to Access GPIOs-Getting permission denied when using open() to access /sys/class/gpio/export

[Brendan Merna]

I'm trying to manipulate my GPIOs using C code and running into "Permission Denied" when running my code and opening the file /sys/class/gpio/export. I'm using nano editor, compiling on the Beaglebone with gcc, and I'm under root user.

I would like to do this, so I can set directions and values for the GPIOs with my code. I've heard this might be a problem with user and kernel space conflicting. I know there are library calls in python and other languages to do this that work. Does anyone know what this problem might be and our their alternate calls I can do in C?

I tried to just include the necessary parts of the code.

Code:

#include<fcntl.h>

static const char *GPIO_PATH = "/sys/class/gpio/export";

int main(){

     int file;

     if ((file = open(GPIO_PATH, O_RDWR))<0){

           perror("GPIO: Can't open the device.");

           return -1;

     }

     return 0;

}

[William Hermans]

debian@beaglebone:~$ cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
debian@beaglebone:~$ sudo cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
debian@beaglebone:~$ sudo su
root@beaglebone:/home/debian# cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
root@beaglebone:/home/debian# ls -al /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Dec 31  1999 .
drwxr-xr-x 59 root root    0 Dec 31  1999 ..
--w-------  1 root root 4096 Dec 31  1999 export
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------  1 root root 4096 Dec 31  1999 unexport
root@beaglebone:/home/debian# whoami
root

read this post . .

http://unix.stackexchange.com/questions/118716/unable-to-write-to-a-gpio-pin-despite-file-permissions-on-sys-class-gpio-gpio18

3rd post or second answer should fix you up. However do note that what you're trying to do is "wrong". Meaning: it is insecure. You ( and I too ) need to read up on process forking. IN short, and perhaps somewhat incorrect( as I'm not 100% up to speed either ) is that you fork a process, running privileged commands, and when that command is done, the privileges are done too . . .

Anyway, probably safer to add your regular user to a group that has limited access to that file.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Also, as I'm unsure what exporting a pin config will do while the system is running . . . you should make 100% absolutely sure you know what you're doing. So you do not fry your board.

[Brendan Merna]

Thanks! That makes a lot of sense now. I figured out I have to open export as write only which agrees with the permissions you showed. I've moved GPIOs to export while the board was running using the command line, so I think its okay.

So changing my code subsituting O_WRONLY for O_RDWR and now I'm getting the error "Writing Error: Device or Resource is busy." It doesn't seem like I can use C code to bring a GPIO to the user space. Is there a way around it?

I'll look up the process forking too.

[William Hermans]

root@beaglebone:/home/debian# echo 0 > /sys/class/gpio/export
root@beaglebone:/home/debian# ls /sys/class/gpio/
export  gpio0  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport
root@beaglebone:/home/debian# echo 0 > /sys/class/gpio/unexport
root@beaglebone:/home/debian# ls /sys/class/gpio/
export  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport

So . . .write only.Here is a decent read on the subject. http://falsinsoft.blogspot.com/2012/11/access-gpio-from-linux-user-space.html

[William Hermans]

DO also keep in mind that /sys/ is a pseudo file system. SO does not always play by the same rules as disk based file systems.

[William Hermans]

Any forward traction ?

[jrb...@colorado.edu]

On Wednesday, July 1, 2015 at 3:19:27 PM UTC-6, William Hermans wrote:

debian@beaglebone:~$ cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
debian@beaglebone:~$ sudo cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
debian@beaglebone:~$ sudo su
root@beaglebone:/home/debian# cat /sys/class/gpio/export
cat: /sys/class/gpio/export: Permission denied
root@beaglebone:/home/debian# ls -al /sys/class/gpio/
total 0
drwxr-xr-x  2 root root    0 Dec 31  1999 .
drwxr-xr-x 59 root root    0 Dec 31  1999 ..
--w-------  1 root root 4096 Dec 31  1999 export
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx  1 root root    0 Dec 31  1999 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------  1 root root 4096 Dec 31  1999 unexport
root@beaglebone:/home/debian# whoami
root

read this post . .

http://unix.stackexchange.com/questions/118716/unable-to-write-to-a-gpio-pin-despite-file-permissions-on-sys-class-gpio-gpio18

3rd post or second answer should fix you up. However do note that what you're trying to do is "wrong". Meaning: it is insecure. You ( and I too ) need to read up on process forking. IN short, and perhaps somewhat incorrect( as I'm not 100% up to speed either ) is that you fork a process, running privileged commands, and when that command is done, the privileges are done too . . .

Anyway, probably safer to add your regular user to a group that has limited access to that file.

The spawned process inherits the real UID (and effective and saved UIDs) from the parent.  But here he needs root to write to the GPIO file.

This is really only a security issue if there are ever other users on the box.  Important security practices for a multiuser machine, yes, but for a BBB acting as (say) a media server with only a wired network connection, not really that important.

[William Hermans]

The spawned process inherits the real UID (and effective and saved UIDs) from the parent.  But here he needs root to write to the GPIO file.

This is really only a security issue if there are ever other users on the box.  Important security practices for a multiuser machine, yes, but for a BBB acting as (say) a media server with only a wired network connection, not really that important.

Fair enough. Though I tend to err on the side of caution, since *sometimes* you never know what can come back and bite you.

By the way, that was my own file system / commands above. No idea what his actual file system groups / permissions looks like.

Since you seem to be more knowledgeable on the subject. What would you suggest that one do in this situation. Assuming the system could be multi user, and internet facing ?

[jrb...@colorado.edu]

On Thursday, July 2, 2015 at 7:37:17 PM UTC-6, William Hermans wrote:

The spawned process inherits the real UID (and effective and saved UIDs) from the parent.  But here he needs root to write to the GPIO file.

This is really only a security issue if there are ever other users on the box.  Important security practices for a multiuser machine, yes, but for a BBB acting as (say) a media server with only a wired network connection, not really that important.

Fair enough. Though I tend to err on the side of caution, since *sometimes* you never know what can come back and bite you.

By the way, that was my own file system / commands above. No idea what his actual file system groups / permissions looks like.

Since you seem to be more knowledgeable on the subject. What would you suggest that one do in this situation. Assuming the system could be multi user, and internet facing ?

This is a big topic... securing an Internet-facing server requires a lot of training on how to write secure software, and it's easy to get it wrong (there are daily reports of breaches when people blow it).  I would say you install only well-known and well-trusted software, go for servers that are known to be more secure (eg, qmail instead of sendmail and djbdns instead of bind).  And if you're writing web apps, take a course in webapp security (OWASP is a good place to start).

Unrelated topic: I've tried to post my own question about the BBB here twice now and it says "your post will appear after it's been approved" but this never happens.  Is the group moderated?  When do the mods come by?  (Sorry to derail the thread!!)

[William Hermans]

Gerald and maybe Jason have the power to approve new users to post. No idea when they'll get on, but do also keep in mind it's the 4th of July weekend( possibly already started for some ) So you may have to wait until Monday.

[William Hermans]

jrblack, also, you can mail me personally, and I'll forward, or just make a new post on your behalf. Assuming I can not answer the question myself.

[Raul Piper]

you can write to gpios by first chmod'ing 666 to the folders and then to individual attributes.

[William Hermans]

I wrote a blog post on this a couple weeks ago as I needed to do the same for a software project I had of my own . . . and figured I'd share. Doing the same for the onboard USR LEDs is a bit problematic specifically when one tries to echo timer > trigger. on_delay and off_delay have eluded my so far when attempting to create a udev rule for them. However, I have not completely given up yet.

http://www.embeddedhobbyist.com/2016/05/beaglebone-black-gpio-permissions/

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fe241815-54f6-4905-a871-e65746420ae4%40googlegroups.com.