On Thu, Feb 13, 2014 at 08:37:47PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02/13/2014 05:40 PM, Chris Wilson wrote:
> > Otherwise, it seems like we need the
> > proxy in order to keep the xrandr property available to users and
> > prevent those who rely upon it in scripts from seeing regressions.
>
> Right, that is what I was thinking too, so the question then becomes how
> hard you will scream at me if I add something like this to xf86-video-intel
> linux specific backlight code:
>
> if (geteuid() == 0) {
> /* Old write directly to /sys/class/backlight/... code */
> {
> else {
> /* The & is to avoid the xserver blocking */
> snprintf(command, sizeof(command), "pkexec %s/libexec/xf86-video-intel-backlight-helper %s %d&",
> PREFIX, sna_output->backlight_iface, level);
> r = system(command);
> if (r) {
> /* complain */
> }
> }
>
> If you won't scream too much, and more importantly, if you will accept such
> a patch (including code for the helper), then I'll try to cook up something
> like this tomorrow.
I feel comfortable enough with that approach, and have nothing better to
suggest. (I would just employ the fallback case if open(O_RDWR) fails.)
And limiting the helper to only write its value into
BACKLIGHT_CLASS/%{iface}/brightness should help reduce its attack surface.
Thinking about it, it would be useful if we verified that BACKLIGHT_CLASS
(both the ddx and its helper)was a sysfs directory in the first place.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
