After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355122 - cpufreq applet requires password to change speed, and doesn't actually changes the speed
cpufreq applet requires password to change speed, and doesn't actually change...
Status: RESOLVED NOTGNOME
Product: gnome-applets
Classification: Other
Component: cpufreq
2.15.x
Other All
: Normal major
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-09 14:26 UTC by Oded Arbel
Modified: 2006-09-26 14:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Oded Arbel 2006-09-09 14:26:33 UTC
Please describe the problem:
When selecting a processor speed from the "Frequencies" list, a password dialog pops up claiming that "You are attempting to run "cpufreq-selector" which may benefit from administrative privileges, but more information is needed in order to do so." and demands the current user's password (BTW - unlike other privilage escalation dialogs which want the root's password).

When the user's password is put in, the cpufreq applet manages to change the governers, but not the actuall processor speed - so governer is put as "userspace", and speed as "800MHz" (on my 1.8GHz centrino, where 800 is the lowest speed) but any attempt to set a higher speed causes the same password popup but fail to affect any change.

Also, choosing "run unprivilged" in the password dialog causes no change to happen without any indication that the operation failed.

Steps to reproduce:
1. left click the CPU freq applet icon. 
2. choose "Frequencies" and a high frequency value.
3. A password dialog pops up. feed in the password and press "Ok"


Actual results:
The governer is set to "userspace" and the frequency to the lowest scale

Expected results:
First, I don't expect the password dialog to popup - it has never done so in 2.14. second, I would expect that after going to the length of inputing my password, there would be some change in the processor speed - which there isn't.

Does this happen every time?
Yes

Other information:
Comment 1 Carlos Garcia Campos 2006-09-09 14:44:36 UTC
What distribution do you have? We are not using any password dialog in the applet.  
Comment 2 Oded Arbel 2006-09-09 15:38:27 UTC
Fedora Core 5.92

I thought a recent update of gnome-applets has put in the privilage limitation setting, but at the moment I can't find it to verify.
/etc/security/console.apps/cpufreq-selector simply says
FALLBACK=true
Also there is an /etc/pam.d/cpufreq-selector which refernces config-util, but I don't get it either.
Comment 3 Oded Arbel 2006-09-09 22:52:15 UTC
Regarding the selector not working - disregard that: something wasn't right with my system and now its ok.

Regarding the security notice - can you help me find what generates it so I know where to open a bug about it (who to blame)?

Thanks
Comment 4 Carlos Garcia Campos 2006-09-12 10:23:26 UTC
cpufreq-selector can be installed suid-root, but it depends on your distribution too. Maybe it's a FC patch to not install it suid-root. 
Comment 5 Oded Arbel 2006-09-12 13:02:38 UTC
On Fedora, cpufreq-selector is installed non-suid-root at /usr/sbin and there is a cpufreq-selector in /usr/bin which is a link to consolehelper from usermode. Running /usr/bin/cpufreq-selector (which is what the cpufreq applet does) calls consolehelper to popup the privelage escelation dialog which - when completed - calls /usr/sbin/cpufreq-selector (not sure of the specific mechanism that consolehelper uses to undertand that /usr/bin/cpufreq-applet is /usr/sbin/cpufreq-applet).

The only configuration that seems relevant for that is /etc/security/console.apps/cpufreq-selector as I noted above, and its the same on FC5 and pre-FC6, although on pre-FC6 it pops the dialog but doesn't on FC5.
Comment 6 Carlos Garcia Campos 2006-09-12 13:43:27 UTC
hmm, cpufreq-selector is now build without lazy bindings (see bug 351695), I don't know whether it has something to do. Anyway, I think it's a distribution specific issue. 
Comment 7 Oded Arbel 2006-09-12 15:11:34 UTC
I'm not sure what are lazy bindings, but the excuse that the binary is suid and the timing of the change seems suspciously like the cause of this problem (mainly as cpufreq-selector in Fedora is not suid root, nor has it ever been so).

If this is indeed the issue, the only question remains, is what is the correct solution - revert the patch from bug 351695 or get Fedora to suid root the cpufreq-selector binary (and drop the consolehelper link). If I understand correctly, I think that the direction we want to go in linux desktop is to have less stuff that is suid, and not more, so it'll probably be harder to get to add the suid bit. I think so, anyway, w/o any actual points for or against.
Comment 8 Carlos Garcia Campos 2006-09-12 18:20:38 UTC
I don't know what's the cause of this problem. cpufreq-selector can be installed suid-root, but do it or not is something that depends on the packager. The reason of installing it suid-root is precisely to avoid a password dialog (which is annoying IMO). By default cpufreq-selector is installed suid-root in $prefix/bin, but your distribution is using a password dialog instead. If you think a password dialog is wrong, open a bug in FC bugzilla. Is this the problem? maybe I don't understand what you want, sorry.
Comment 9 Oded Arbel 2006-09-12 21:35:47 UTC
Yes, that's my problem - the password dialog. But why did the behavior change ? it wasn't suid before either.
Comment 10 Carlos Garcia Campos 2006-09-14 19:25:55 UTC
We haven't added a password dialog, so I think it's something that has been changed in your distro. I would like to help you, but I don't know anything about Fedora, sorry.
Comment 11 Oded Arbel 2006-09-17 17:42:55 UTC
What about those lazy bindings ? can't it be related ? From the issue description (of Bug 351695) I understand that lazy bindings was used only for non-suid root installations, and since cpufreq-selector is always suid, then these are not needed. Only problem, is it isn't always suid root - Fedora doesn't set it suid root.

The way I'm reading it, is that is used to work ok on Fedora on which cpufreq-selector isn't suid root, but once lazy binding was removed it stopped working properly.
Comment 12 Oded Arbel 2006-09-26 14:25:58 UTC
I'm assuming this is a Fedora Core only issue, and as the bug I opened in the RedHat bugzilla (206207: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206207) was closed as fixed, I'm resolving this bug as well.