udev crea las reglas correctas, pero los derechos desaparecen tan pronto como bash acceder a los files a través de C ++

Estoy enfrentando un problema realmente extraño al usar udev. Como ya expliqué aquí , bash acceder a algunas carpetas / files como un usuario sin root. Aquí están mis reglas de udev para la carpeta gpio:

KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R dave:users /sys/class/gpio; chmod -R 777 /sys/class/gpio'" KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R dave:users /sys/class/virtual/gpio; chmod -R 777 /sys/class/virtual/gpio'" KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R dave:users /sys%p; chmod -R 770 /sys%p'" 

que se aplican de la manera correcta como se espera que haga. De hecho, después de un reinicio obtengo los derechos que definí en las reglas:

 dave@arm:~$ ls -l /sys/class/gpio/ total 0 -rwxrwxrwx 1 dave users 4096 Jan 9 20:56 export lrwxrwxrwx 1 dave users 0 Jan 9 20:56 gpiochip0 -> ../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 dave users 0 Jan 9 20:56 gpiochip32 -> ../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32 lrwxrwxrwx 1 dave users 0 Jan 9 20:56 gpiochip64 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64 lrwxrwxrwx 1 dave users 0 Jan 9 20:56 gpiochip96 -> ../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96 -rwxrwxrwx 1 dave users 4096 Jan 9 20:56 unexport 

Ahora: sucede algo realmente extraño. Escribí un sencillo progtwig en C ++ que usa las bibliotecas de impulso para acceder y escribir en files. Aquí publico un scracth de mi progtwig que consiste en classs solo como un ejemplo:

 /* * @brief drives the gpio-pin high or low * @param the pin number, the state (high or low) * @return the success of the operation * */ int GPIOclass::digitalWrite( unsigned int pin_label, unsigned int state ) { /* Check whether the Pin state has been correctly set or not */ if( ( state != HIGH ) && ( state != LOW ) ) { std::cerr << "WARNING: Check again the value you want to write. It must be HIGH or LOW!" << std::endl; return EXIT_FAILURE; } /* Write the desinetworking Pin value */ boost::filesystem::fstream fs; boost::filesystem::path path_pin = "/sys/class/gpio"; path_pin /= "/gpio" + std::to_string( pin_label ); path_pin /= "/value"; fs.open( path_pin, std::fstream::out ); if( fs.is_open() ) { fs << state; fs.close(); } else { std::cerr << "ERROR: I couldn't open " << path_pin << " file" << std::endl; return EXIT_FAILURE; } return EXIT_SUCCESS; } 

Lo extraño es que no puedo acceder al pin requerido, porque en la carpeta exportada encontré solo un enlace y no los files y carpetas habituales para manejar el gpio. Lo que encuentro es la única input:

 dave@arm:~$ ls -l /sys/class/gpio/gpio60 lrwxrwxrwx 1 dave users 0 Jan 9 20:58 /sys/class/gpio/gpio60 -> ../../devices/platform/ocp/4804c000.gpio/gpio/gpio60 

Pero yendo al directory puedo ver más files y carpetas que arriba:

 dave@arm:/sys/class/gpio/gpio60$ ls -l total 0 -rwxrwx--- 1 dave users 4096 Jan 9 21:11 active_low lrwxrwxrwx 1 dave users 0 Jan 9 21:11 device -> ../../../4804c000.gpio -rwxrwx--- 1 dave users 4096 Jan 9 21:11 direction -rwxrwx--- 1 dave users 4096 Jan 9 21:11 edge drwxrwx--- 2 dave users 0 Jan 9 21:11 power lrwxrwxrwx 1 dave users 0 Jan 9 21:11 subsystem -> ../../../../../../class/gpio -rwxrwx--- 1 dave users 4096 Jan 9 21:11 uevent -rwxrwx--- 1 dave users 4096 Jan 9 21:11 value 

así que parece que hay algunas reglas de visibilidad o algo así. ¿Por qué obtengo 2 resultados diferentes si miro la carpeta desde el exterior o si miro desde el interior de la carpeta ?

Comenzar el mismo progtwig usando sudo funciona perfectamente.


ACTUALIZACIÓN: Hice exactamente lo que sugerí en la respuesta a continuación. La respuesta es correcta, pero no puedo usar el gpio exportado como un usuario normal. Así que estoy buscando una nueva regla que me permita cambiar el grupo y el propietario de la carpeta vinculada:

 /sys/devices/platform/ocp/4804c000.gpio 

como se sugiere en la respuesta.

El problema ahora es que estoy tratando de escribir una nueva regla que hace exactamente eso. Una vez que recuperé la siguiente información:

 @arm:~/workspace/auto/build$ udevadm info --path=/sys/devices/platform/ocp/4804c000.gpio --attribute-walk Udevadm i... looking at device '/devices/platform/ocp/4804c000.gpio': KERNEL=="4804c000.gpio" SUBSYSTEM=="platform" DRIVER=="omap_gpio" ATTR{driver_override}=="(null)" looking at parent device '/devices/platform/ocp': KERNELS=="ocp" SUBSYSTEMS=="platform" DRIVERS=="" ATTRS{driver_override}=="(null)" looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS=="" 

Agregué las siguientes reglas a mi regla de udev existente:

 KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/class/gpio; chmod -R 777 /sys/class/gpio'" KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/class/virtual/gpio; chmod -R 777 /sys/class/virtual/gpio'" KERNEL=="gpio*", SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys%p; chmod -R 776 /sys%p'" KERNEL=="4804c000.gpio", SUBSYSTEM=="platform", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/devices/platform/ocp/4804c000.gpio; chmod -R 777 /sys/devices/platform/ocp/4804c000.gpio'" KERNEL=="481ae000.gpio", SUBSYSTEM=="platform", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/devices/platform/ocp/481ae000.gpio; chmod -R 777 /sys/devices/platform/ocp/481ae000.gpio'" KERNEL=="481ac000.gpio", SUBSYSTEM=="platform", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/devices/platform/ocp/481ac000.gpio; chmod -R 777 /sys/devices/platform/ocp/481ac000.gpio'" KERNEL=="44e07000.gpio", SUBSYSTEM=="platform", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R bbb:gpio /sys/devices/platform/ocp/44e07000.gpio; chmod -R 777 /sys/devices/platform/ocp/44e07000.gpio'" 

Funcionando como un usuario normal, sigo recibiendo el siguiente error:

 ERROR: I couldn't open "/sys/class/gpio/gpio67/value" file ERROR: I couldn't open "/sys/class/gpio/gpio69/value" file ERROR: I couldn't open "/sys/class/gpio/gpio66/value" file ERROR: I couldn't open "/sys/class/gpio/gpio69/value" file 

de mi progtwig C ++ arriba.

Realmente no puedo entender ya que los derechos están establecidos correctamente:

 bbb@arm:~/workspace/build$ ls -l /sys/class/gpio/gpio60/ total 0 -rwxrwxrw- 1 bbb gpio 4096 Jan 11 17:50 active_low lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 device -> ../../../4804c000.gpio -rwxrwxrw- 1 bbb gpio 4096 Jan 11 17:50 direction -rwxrwxrw- 1 bbb gpio 4096 Jan 11 17:50 edge drwxrwxrw- 2 bbb gpio 0 Jan 11 17:50 power lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 subsystem -> ../../../../../../class/gpio -rwxrwxrw- 1 bbb gpio 4096 Jan 11 17:50 uevent -rwxrwxrw- 1 bb gpio 4096 Jan 11 17:50 value 

y el problema con el enlace parece estar solucionado ahora:

 bbb@arm:~/workspace/build$ ls -l /sys/class/gpio total 0 -rwxrwxrwx 1 bbb gpio 4096 Jan 11 17:50 export lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio48 -> ../../devices/platform/ocp/4804c000.gpio/gpio/gpio48 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio60 -> ../../devices/platform/ocp/4804c000.gpio/gpio/gpio60 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio66 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpio66 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio67 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpio67 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio68 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpio68 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:50 gpio69 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpio69 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:49 gpiochip0 -> ../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:49 gpiochip32 -> ../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:49 gpiochip64 -> ../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64 lrwxrwxrwx 1 bbb gpio 0 Jan 11 17:49 gpiochip96 -> ../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96 -rwxrwxrwx 1 bbb gpio 4096 Jan 11 17:49 unexport 

¿Qué estoy haciendo mal?


ACTUALIZACIÓN: Realmente estoy teniendo dificultades para tratar de entender lo que está pasando en esta distribución. Llegué con este ejemplo mínimo (en este enlace puede encontrar los cmakelists para comstackrlo) para abrir y escribir en las carpetas exportadas para cada pin. Ahora estoy usando beaglebone (con ubuntu). Las reglas del uder están definidas arriba. No los cambié.

Al tratar de ejecutar el progtwig con mi usuario "bbb" obtengo los siguientes errores:

 bbb@arm:~/workspace/auto/test/build$ ./myprog ERROR: the direction of pin "/sys/class/gpio/gpio67/direction" cannot be set. Reason: Permission denied ERROR: the value of the "/sys/class/gpio/gpio67/value" cannot be defined. Reason: Permission denied ... 

Agregué el usuario "bbb" a todos los grupos que pertenecen al usuario pnetworkingeterminado "ubuntu".

¿Que puedo hacer?

Solutions Collecting From Web of "udev crea las reglas correctas, pero los derechos desaparecen tan pronto como bash acceder a los files a través de C ++"

/sys/class/gpio/gpio60 es un enlace simbólico . Ese es un tipo especial de file que apunta a otro file. Al acceder al contenido del file, los enlaces simbólicos son transparentes: actúan como su objective (el file al que apuntan). Pero al enumerar directorys, los enlaces simbólicos aparecen como ellos mismos; ls -l muestra con l en la columna de la izquierda, y muestra su objective después de -> a la derecha. Al acceder a los metadatos, depende.

chmod -R … /sys/class/gpio afecta al tree de directorys que comienza en /sys/class/gpio . Esto incluye inputs tales como /sys/class/gpio/gpio60 . Pero /sys/class/gpio/gpio60 es un enlace simbólico, que apunta a otro lugar en el tree de directorys; el command chmod no afecta el objective del enlace simbólico.

Cuando intenta acceder a los files en /sys/class/gpio/gpio60 , o cuando ejecuta cd /sys/class/gpio/gpio60 , accede al directory al que apunta el enlace simbólico (acceso al contenido del directory). Esto funciona como raíz pero no como no raíz porque ese directory es accesible solo a la raíz.

Para hacer que ese directory sea accesible para otros usuarios, necesitaría ejecutar chmod … /sys/devices/platform/ocp/4804c000.gpio/gpio/gpio60 .

Sin embargo, en lugar de cambiar la propiedad, sería más sencillo agregar su usuario al grupo gpio :

 adduser dave gpio