I was planning to upgrade, so I ran this:
apk update --simulate
apk update
#same number of packages
apk upgrade --simulate

Having run a polkit-free system for several years, I was not happy to see
"adding polkit". (In my past experience, it is a royal pain to get working
right if you use startx and a minimal window manager.
And when it was working, plain authentication worked better for me than the
policies...)

After reading up, I figured out that it was a precaution for the
brightness helper that xf86-video-intel ships with, related to a CVE in
that helper (it was writing to /sys/class/backlight/%s/brightness,
where %s could be any valid portion of a path name).

Now, as an aside:
The latest version of that helper checks for the presence of '/' in the
command line and exits if found.
This theoretically would still allow writing a new file with one of two
names (/sys/class/brightness or /sys/class/backlight/brightness) if you
use '.' or '..' as the path, except the open/fstat test handles that.


Anyhow, I tested my laptop, and found that I can change the brightness
even if the helper is chmod a-x.
So I wrote the attached apkbuild to satisfy the polkit dependency.
I'd guess that it should not be added to the main repo, since it might
cause an automatic "upgrade"; but some people might find it handy.

Thanks,
Isaac Dunham

Aside: I have X starting at boot as a user via this line in inittab:
::once:/bin/su -c "xinit 2>/dev/null >&2" -l idunham

On Sat, 13 Sep 2014 08:25:25 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> I was planning to upgrade, so I ran this:
> apk update --simulate
> apk update
> #same number of packages
> apk upgrade --simulate
> 
> Having run a polkit-free system for several years, I was not happy to see
> "adding polkit". (In my past experience, it is a royal pain to get working
> right if you use startx and a minimal window manager.
> And when it was working, plain authentication worked better for me than the
> policies...)

I think we should respect polkit-free setups, so sorry about this.

> After reading up, I figured out that it was a precaution for the
> brightness helper that xf86-video-intel ships with, related to a CVE in
> that helper (it was writing to /sys/class/backlight/%s/brightness,
> where %s could be any valid portion of a path name).
> 
> Now, as an aside:
> The latest version of that helper checks for the presence of '/' in the
> command line and exits if found.
> This theoretically would still allow writing a new file with one of two
> names (/sys/class/brightness or /sys/class/backlight/brightness) if you
> use '.' or '..' as the path, except the open/fstat test handles that.

I removed the suid root bit from the helper program and it didnt break
anything for me.

> Anyhow, I tested my laptop, and found that I can change the brightness
> even if the helper is chmod a-x.

Xorg probably runs as root.

> So I wrote the attached apkbuild to satisfy the polkit dependency.
> I'd guess that it should not be added to the main repo, since it might
> cause an automatic "upgrade"; but some people might find it handy.

I think we can remove the polkit dependency from xf86-video-intel for now.

You can apk add '!polkit' to create a conflict. It will prevent
anything that tries to pull in polkit.


> Thanks,
> Isaac Dunham
> 
> Aside: I have X starting at boot as a user via this line in inittab:
> ::once:/bin/su -c "xinit 2>/dev/null >&2" -l idunham

I think Xorg is suid root...

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Mon, 15 Sep 2014 11:23:12 +0200
Natanael Copa wrote:

> > So I wrote the attached apkbuild to satisfy the polkit dependency.
> > I'd guess that it should not be added to the main repo, since it might
> > cause an automatic "upgrade"; but some people might find it handy.  
> 
> I think we can remove the polkit dependency from xf86-video-intel for now.
> 
> You can apk add '!polkit' to create a conflict. It will prevent
> anything that tries to pull in polkit.

In case anyone doesn't know as it wasn't in plain sight for me, you can
also disable polkit by removing it's file in 

/usr/share/dbus-1/system-services 

Useful if you install lots of stuff and find you have no need for
it and are perhaps using sudo more securely but upstreams are
arrogant/idiots/ignorant or a mix of the aforementioned.

You may also want chmod -s pkexec and these two things adding to a
boot script.

As a side note logind after one upgrade started correcting it's
permissions and so I had to change the strategy to removing the
binary on boot all together.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Sat, 13 Sep 2014 08:25:25 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> I was planning to upgrade, so I ran this:
> apk update --simulate
> apk update
> #same number of packages
> apk upgrade --simulate
> 
> Having run a polkit-free system for several years, I was not happy to see
> "adding polkit". (In my past experience, it is a royal pain to get working
> right if you use startx and a minimal window manager.
> And when it was working, plain authentication worked better for me than the
> policies...)

I removed the polkit dependency of xf86-video-intel.

Thanks for reporting and analyzing it.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---