I control backlight through /sys/class/backlight/acpi_video0/brightness with a script (via sudo) that provides a simple script to increment/decrement, set, retrieve and restore last backlight setting on desktop start. xrandr isn't an option as the Nvidia interface is through the sysfs device.

I have written a simple Qt interface that provides a slider and spinbox to accomplish the same thing, but I'm stuck on how to provide elevated privilege to the program to enable a user to modify the setting without resorting to su or sudo through some execv or system interface.

This is not a duplicate of Control backlight as a user (without xbacklight). (that's what I'm doing already with the script)

The question is more a program design approach question (which would be a bit general for SO). What I don't understand is whether it is better to:

  1. write a udev rule to change the permissions, allow the user to change brightness, and then a second rule to restore the original permissions? (but then how to trigger the rules from within the program?)
  2. write a udev rule to change the permissions for the user for the entire desktop session (acceptable - not first choice, but then how to trigger the rule on user login rather than at boot?)
  3. use some other privilege elevation within the code that I have yet to stumble across?

It seems like there should be a straight forward and general solution for this, but after working through the udev documentation, rules to change and restore the permissions (or OWNER or GROUP) of the sysfs file are straight-forward, but how to trigger the change on program start and then restore the original perms on exit.

My preference is to handle the change within the program so that the sysfs device isn't altered, except immediately before the write to /sys/class/backlight/acpi_video0/brightness and then restored immediately after.

I am no udev guru, I've basically read the man page, and 1/2 dozen tutorials and the Archwiki page. In doing so, I have not run across a programmatic way to trigger rules from C/C++ (or I didn't recognize it when I saw it). So I'm not certain that udev would provide a solution, but from a file permission standpoint, that seemed a better area of investigation than looking for a secure way to elevate privileges for the program itself.

So, udev at all? If so, triggered within the code - how? Or, settle for changing permissions for the sysfs file for the entire desktop session? -- but then how to trigger at desktop start instead of at boot?

If not udev, then what secure way to approach a temporary privilege elevation to enable a direct write to the sysfs file?

Worst case, I could use execv or system to simply call the script and let sudo handle it, but I'm looking for a more elegant way to handle it for all users without having to configure /etc/sudoers for each and make each a member of the wheel or sudo groups.

  • I can’t write a detailed answer right now, but this sounds like a job for PolicyKit, not udev. – Stephen Kitt Jul 25 at 21:09
  • @StephenKitt thank you! I had not thought of polkit, but that looks like a very fruitful avenue. I'll digest that information and see if a solution is hiding there somewhere. – David Rankin - ReinstateMonica Jul 26 at 0:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.