Start a new topic

Exporting tsmicroctl, leds and /dev/wilc_bt to non root user - udev rules

Hi,


I'm trying to export functionality for the TS-7553-V2 for a non root user, called pi.

The functionality is tsmicroctl, gpios and leds and it all revolves around udev rules


  1. No output from tsmicroctl

# groups pi                                   
pi : pi tty sudo staff netdev bluetooth gpio

# ls -l /usr/local/bin
total 196
-rwxr-xr-x 1 root staff 24724 Apr  2  2019 bounce-test
-rwxr-xr-x 1 root staff 23592 Apr  2  2019 cairo-test
-rwxr-xr-x 1 root root    228 Apr  2  2019 firstboot
-rwxr-xr-x 1 root staff 22812 Apr  2  2019 gpioctl
-rwxr-xr-x 1 root staff 26968 Apr  2  2019 keypad-test
-rwxr-xr-x 1 root staff 27000 Apr  2  2019 lcd-helper
-rwxr-xr-x 1 root staff 24424 Apr  2  2019 tshwctl
-rwxr-xr-x 1 root staff 23636 Apr  2  2019 tsmicroctl
-rwxr-xr-x 1 root staff  1193 Apr  2  2019 tssilomon
-rwxr-xr-x 1 root staff   477 Mar  4 23:10 udev-gpio-permissions.sh
-rwxr-xr-x 1 root staff   713 Mar  5 19:02 udev-led-permissions.sh

 User pi is member of group staff. When I run tshwctl and tsmicroctl I see 2 very different outputs


 2.  Exporting /sys/class/leds - No write privileges, only read. I believe there is something wrong with my udev rules


I'm using udev rules to set the permissions on /sys/class/leds/<ledname>/brightness 

   

root@ts-imx6ul:~# cat /etc/udev/rules.d/80-led-permissions.rules 
KERNEL=="leds", SUBSYSTEM=="subsystem", ACTION=="add", PROGRAM="/usr/local/bin/udev-led-permissions.sh"

root@ts-imx6ul:~# cat /usr/local/bin/udev-led-permissions.sh     
#!/bin/bash

chown -R pi:gpio /sys/class/leds

chown -R pi:gpio /sys/class/leds/red-led/brightness
chmod 660 /sys/class/leds/red-led/brightness
chown -R pi:gpio /sys/class/leds/green-led/brightness
chmod 660 /sys/class/leds/green-led/brightness
chown -R pi:gpio /sys/class/leds/en-modem-5v/brightness
chmod 660 /sys/class/leds/en-modem-5v/brightness
chown -R pi:gpio /sys/class/leds/en-xbee-3v3/brightness
chmod 660 /sys/class/leds/en-xbee-3v3/brightness
chown -R pi:gpio /sys/class/leds/en-usb-5v/brightness
chmod 660 /sys/class/leds/en-usb-5v/brightness
 

 3. /dev/wilc_bt - cannot echo to /dev/wilc_bt

 

root@ts-imx6ul:~# cat /etc/udev/rules.d/81-wilc-bt-permissions.rules 
KERNEL=="wilc_bt", SUBSYSTEM=="atmel", ACTION=="add", PROGRAM="/usr/local/bin/udev-wilc-bt-permissions.sh"

root@ts-imx6ul:~# cat /usr/local/bin/udev-wilc-bt-permissions.sh     
chown -R pi:bluetooth /dev/wilc_bt
chmod 660 /dev/wilc_bt

pi@ts-imx6ul:~$ echo BT_POWER_SLEEP > /dev/wilc_bt
-bash: /dev/wilc_bt: Permission denied

 Thanks


For tsmicroctl and tshwctl this is what I see as user


```

pi@ts-imx6ul:~$ tshwctl -i

model=7553

boardopt=255

pi@ts-imx6ul:~$ tsmicroctl -i

pi@ts-imx6ul:~$

```

Good evening Valens,

Normally I don't get involved with complex user management (most of the time our systems are single-user embedded systems where such management is unnecessary), so I had to get a couple other engineers involved.

We found the -R switch tends to get confused and confounded by symbolic links, so we did this:

useradd user
groupadd gpio
usermod -a -G gpio user

Create /etc/udev/rules.d/99-leds.rules:
SUBSYSTEM=="leds*", PROGRAM="/bin/sh -c 'find -L /sys/class/leds/ -maxdepth 2 -exec chown user:gpio {} \; -exec chmod 770 {} \; || true'"

Other tools really do rely on root access.  For example tsmicroctl can literally take down the system, so while you could give an unprivileged user access, that would be going against the general idea of having privileged users.  I would imagine with the above knowledge you could add privileges as you see fit, but we wouldn't recommend it.

Best Regards,
________________________________________________________________
Michael Peters, Technologic Systems   | voice: (480) 837-5200
16525 East Laser Drive                | fax: (480) 837-5300
Fountain Hills, AZ 85268              | web: www.embeddedARM.com
---
Please rate your satisfaction:
UnsatisfiedNeutralSatisfied
Login or Signup to post a comment