led-class.c permission change

Hi,

This patch changes the led brightness file's permissions to 0666, so that a user's MUA can light up the mail LED without needing root permissions.

Thanks!

@@ -56,7 +56,7 @@ static ssize_t led_brightness_store(stru
 	return ret;
 }
 
-static CLASS_DEVICE_ATTR(brightness, 0644, led_brightness_show,
+static CLASS_DEVICE_ATTR(brightness, 0666, led_brightness_show,
 			led_brightness_store);
 #ifdef CONFIG_LEDS_TRIGGERS
 static CLASS_DEVICE_ATTR(trigger, 0644, led_trigger_show, led_trigger_store);

NAK.

The management of user specific temporary permissions belongs in user space with a safe "no" default value to stop background daemons doing silly things.

Take a look at the various pam console management modules (and also beat people up to get revoke() support into the kernel).

Alan

On 05 May 2007 at 22h05, Alan Cox wrote:

Hi,

Mmh, ok... My usage pattern for this is for an MUA plugin[1] that does write 1 to /sys/class/leds/asus:mail/brightness, for example, when new mail comes. The MUA typically runs as user and until now most of the handled LEDs had no such permission problems (/proc/acpi/asus/mled, /proc/acpi/acer/mailled etc).

So, I've got to find a way to write into that file as user so that things automatically work.

So, you suggest me to link my plugin to libpam and find something that allows the plugin to write into /brightness?

Thanks,

[1] http://www.claws-mail.org/plugin.php?plugin=acpinotifier

Colin

Much simpler than that. Most distributions have a pam module already which updates permissions on things that the "console" user may want to access directly (eg /dev/audio* /dev/cdrom etc) but which should otherwise be protected from misuse (eg people with cronjobs that run eject - an old an very funny SunOS prank)

If your distribution is like most and uses pam_console then see man 5 console.perms and add a rule to the /etc/security/console.perms file for your file. At that point it will happily change the rights back and forth for you as required.