# Udev rule for /sys/class/leds/

## AustrianCoder

Hi all.

I am running in some issues with changing permissions of /sys/class/leds/

```

root@OT:~# ls /sys/class/leds/buzzer/ -l

total 0

-rw-r--r-- 1 root root 4096 Aug 22 13:49 brightness

-rw-r--r-- 1 root root 4096 Aug 22 13:49 delay_off

-rw-r--r-- 1 root root 4096 Aug 22 13:49 delay_on

lrwxrwxrwx 1 root root    0 Aug 22 13:49 device -> ../../../leds-gpio.0

-r--r--r-- 1 root root 4096 Aug 22 13:49 max_brightness

lrwxrwxrwx 1 root root    0 Aug 22 13:45 subsystem -> ../../../../../class/leds

-rw-r--r-- 1 root root 4096 Aug 22 13:49 trigger

-rw-r--r-- 1 root root 4096 Aug 22 13:45 uevent

```

I want that every user could write to brightness trigger and delay_on/off if these files exist. The biggest

problem is that if I change the trigger to none and back to timer only root can access delay_on/off as

these two files got removed and recreated during trigger change.

This is my try for an udev rule:

```

SUBSYSTEM=="leds", MODE="0777"

```

And here are some other useful informations:

```

root@OT:~# udevadm info --path=/sys/class/leds/buzzer --query=all  --attribute-walk 

custom logging function 0xb8a4b008 registered

selinux=0

calling: info

device 0xb8a4b078 has devpath '/devices/platform/leds-gpio.0/leds/buzzer'

Udevadm info starts with the device specified by the devpath and then

walks up the chain of parent devices. It prints for every device

found, all possible attributes in the udev rules key format.

A rule to match, can be composed by the attributes of the device

and the attributes from one single parent device.

  looking at device '/devices/platform/leds-gpio.0/leds/buzzer':

    KERNEL=="buzzer"

    SUBSYSTEM=="leds"

    DRIVER==""

    ATTR{brightness}=="0"

    ATTR{max_brightness}=="255"

    ATTR{trigger}=="none [timer] heartbeat "

    ATTR{delay_on}=="0"

    ATTR{delay_off}=="0"

device 0xb8a4b3f0 has devpath '/devices/platform/leds-gpio.0'

  looking at parent device '/devices/platform/leds-gpio.0':

    KERNELS=="leds-gpio.0"

    SUBSYSTEMS=="platform"

    DRIVERS=="leds-gpio"

    ATTRS{modalias}=="platform:leds-gpio"

device 0xb8a4b610 has devpath '/devices/platform'

  looking at parent device '/devices/platform':

    KERNELS=="platform"

    SUBSYSTEMS==""

    DRIVERS==""

```

I am quite happy about any hint

----------

## avx

Don't know much about udev, but if only the goal matters, why not just simply create a file like /etc/local.d/set_led_perms.start and use a `chmod 777 $files` in it?

----------

## AustrianCoder

Sorry for the late answer.

The problem is that device nodes gets created and deleted if I change the trigger. And the new created files

are only accessible as root.

----------

## grey_dot

udev doesn't manage /sys filesystem, only the /dev one. /sys is totally managed by kernel.

upd: and, in case you might ask, placing led interface in /dev will most likely require modifing the corresponding kernel driver. Though, it might not be such a bad idea :) Btw, FreeBSD has /dev/led/ directory with nodes to manage leds status.

----------

## avx

 *AustrianCoder wrote:*   

> Sorry for the late answer.
> 
> The problem is that device nodes gets created and deleted if I change the trigger. And the new created files
> 
> are only accessible as root.

 Then setup a some kind of watching script, around inotify maybe, that triggers on demand.

----------

## grey_dot

 *avx wrote:*   

>  *AustrianCoder wrote:*   Sorry for the late answer.
> 
> The problem is that device nodes gets created and deleted if I change the trigger. And the new created files
> 
> are only accessible as root. Then setup a some kind of watching script, around inotify maybe, that triggers on demand.

 

Changing permissions on /sys files is not a really wise idea. I'd write a suid script that echoes whatever needed to those files instead.

----------

