/usr/bin/cpufreq-selector should have different access permissions

The /usr/share/doc/gnome-applets-data/README.Debian file mentions the current
situation, there is a debconf "low" question about this, NOTABUG

The current dpkg-reconfigure of this package does not use the fact that ubuntu
has the admin group and will thus set the permissions too open. Given this group
I think it makes perfect sense to change the default to let admin users (or
maybe even a new group) change the CPU speed via the GUI.

had admin the rights to change the cpufreq?

Admins *should* have this access, that's why the setuid bit should be set (and
the u+x bit not). The nicest approach would be a separate group which also has a
nice description in the gnome-system-tools. The initial user should
automatically become a member of this group. If this approch sounds good, I can
make patches for g-s-t, the installer and gnome-applets to support this.

Currently, the admin group is not used for any similar purpose. It is only
defined as providing sudo access via the default entry in /etc/sudoers. It is
not at all obvious that this should be changed.

That why I made the other suggestion of adding a systeem group.

Oh, please, not another setuid root application if we can avoid it. Which file
does cpufreq-selector need access to to change the CPU speed? And why should a
normal user be able to change the CPU speed in the first place? The automatic
CPU speed works well enough for the majority of users, and control freaks can
always use sudo to manually set the speed, or deliberately shoot themselves in
the foot by making the binary suid root (as explained in README.Debian).

From my POV the current situation is fine.

It access the files /sys/devices/system/cpu/cpu*/cpufreq/*

It has been a very often requested thing on #ubuntu, that's why I think it would
be nice to have.

Confirming this.

Personal note: It makes the applet much more usable to be able to change the frequency. Right now, I have to read the README.Debian and change things. Even an option to tell the user to read README.Debian would be nicer than what we have presently.

Entries in /sys can be chown'd and chmod'd:

Perhaps /sys/devices/system/cpu/cpu*/cpufreq/* could be chgrp'd to admin and chmod'd 664 on boot? (And cpufreq selector made to just test if it can write to the files it needs before complaining). In fact, it's really just a handful of files that need chmod'ing, not the entire directory.

No suid root need.

Although perhaps we want some scripts to run in order to do this chmodding when CPUs are hotplugged too ;)

The situation in which I want to change the frequency arises when I'm running one compute-intensive background job per CPU at 'nice 5' so that I get decent performance in interactive jobs as well; it seems that the default governor regards the situation in which niced jobs are using 100% of the CPU as one in which it can happily set the speed down to 1GHz, which is not at all what I want. Possibly fixing that is more like the Right Answer.

BernardB has I think got it right.

@Martin: Normal Users like myself would find this feature very useful. I have a Notebook, and when running on Batteries this would be a useful thing. Why hiding such things from the Users?

Hi everybody,

I think this the right place to post this... Sorry if it is not.

I have tried to configure Gnome frequency selector to have properly working governors, since as someone wrote above it is generally nice to leave the "ondemand" setting do its business without worrying about it, but when battery life (on a laptop) is a premium, having the possibility to reduce the CPU speed to a fix value makes sense. I know some of you gurus will tell me that there is a way to do this from the command line... Well, ok, but that doesn't get 90% of us very far !

So, here is what I found about the Gnome frequency selector (under Feisty): If I install it without any superuser rights, I don't get to choose the frequency from the GUI (=> battery life problem) but it does vary depending on the CPU workload as it should. If I do a dpkg-reconfigure gnome-applets to give it superuser privileges, I can choose the CPU speed manually... BUT the governors, although available, do not work !! So, it's a bit cheese OR dessert, if you see what I mean.

Is this because of various access rights not being what they should ?

Thank you for your help,

Arnaud.

With inclusion of apparmor in Gutsy. Can this be the solution to have cpufreq-selector with the suid bit set ?!

Yes, in theory we could confine cpufreq-selector to only be able to read and write the relevant files in /sys/devices/system/cpu/cpu*/cpufreq/*, maybe read some configuration files, and not much else. If the suid root part is a very small program which just does that one thing, it should be easy to create an apparmor profile. Judging by the file size and linked libraries, this seems to be the case.

Any update on this? Suid set together with AppArmor profile something for Intrepid? Anyone here that already know how to configure this apparmor profile?

For those who want to enable frequency scaling right away, read the official docs, this howto ( http://www.ubuntugeek.com/howto-change-cpu-frequency-scaling-in-ubuntu.html ), this blog post ( http://ubuntu.wordpress.com/2005/11/04/enabling-cpu-frequency-scaling/ ) or simply run:

sudo dpkg-reconfigure gnome-applets

And answer Yes.

Hi,

Thank you very much for your help, but I have enabled the frequency scaling
using that same "sudo dpkg-reconfigure gnome-applets" command before.

I actually don't know how to close this topic, but on a more general note,
going to Hardy Heron solved the problem.

Regards,

A. Léandre.

2008/6/23 Motin <email address hidden>:

> Any update on this? Suid set together with AppArmor profile something
> for Intrepid? Anyone here that already know how to configure this
> apparmor profile?
>
> For those who want to enable frequency scaling right away, read the
> official docs, this howto ( http://www.ubuntugeek.com/howto-change-cpu-
> frequency-scaling-in-ubuntu.html<http://www.ubuntugeek.com/howto-change-cpu-frequency-scaling-in-ubuntu.html>), this blog post (
> http://ubuntu.wordpress.com/2005/11/04/enabling-cpu-frequency-scaling/ )
> or simply run:
>
> sudo dpkg-reconfigure gnome-applets
>
> And answer Yes.
>
> --
> /usr/bin/cpufreq-selector should have different access permissions
> https://bugs.launchpad.net/bugs/23768
> You received this bug notification because you are a direct subscriber
> of the bug.
>

the current intrepid version uses policykit now, closing the bug

Aha great, so frequency scaling with cpufreq-selector is finally enabled by default again in Intrepid?

And disabled again in koala :(

See http://ubuntuforums.org/showthread.php?t=1299820 for a workaround fix.

Hello, just to say that not only geeks care about cpufreq-selector but experience revealed that I need it to be more performant and accurate. Actually my laptop is overheating when OnDemande mode is set (I suppose because fan control is not adapted but I didn't manage to know yet). Anyway, I also don't understand why "not another setuid root application" is so awful that they should "avoid it" but I just say that it may be interesting to put it as a feature to normal ubuntu users.

ybaruss, this has been fixed for good over two years ago.