> > *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 ? On Thu, Jul 2, 2015 at 6:17 PM, <jrbl...@colorado.edu> wrote: > > > 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. > > > >> >> >> On Wed, Jul 1, 2015 at 8:02 AM, Brendan Merna <bmer...@gmail.com> wrote: >> >>> >>> 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; >>> } >>> >>> -- >>> 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. >>> >> >> -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
