Battery Status

Need to input root password twice to change scaling

Bug #585793 reported by Omar Campagne

This bug report was converted into a question: question #112581: How to disable [root] password asking on each CPU frequency scaling change?.

6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Battery Status
Invalid
Undecided
Unassigned

Bug Description

Hi again.

Steps:
Open menu and select a different governor.

Expected result:
One dialog prompt asking for the password.

Result:
Two dialog prompts (one after the other) asking for input.
Sometimes it lags between one dialog and the second, the only time it asked
just once for my password it froze for half a minute (yet it did change the governor).

I tried --window but there is no debug information there.

policykit package has version 0.9-4. policykit-1-gnome is 0.96, Debian Squeeze AMD64,
I am using the lucid packages, since this time Ubuntu and Debian Testing are a bit more synced
(more than Karmic - Squeeze in most cases).
I have to add that the permission disappears as soon as it changes the governor.
I know it's working through org.gnome-cpufreqselector, yet the gnome-applet does remember the
privilege till the end of the session (different bug?)

Can't see any log that could help, tried cat whatever | grep cpufreq/policykit.

Revision history for this message
Ivan Zorin (iaz) wrote :

And thanks again for bug.
I have some thoughts about this.
First, I guess that your hardware has a couple CPUs, right? (so looks like battery-status asking password for each CPU, because unlike cpufreq-applet, battery-status changes frequency scaling not only for first/primary CPU, but for other(s) also).
Second, the point is that when battery-status handle frequency scaling, battery-status doesn't handle rights/permissions/policies and other such stuff - it just ask cpufreq for switching frequency; what's going on next - depends on environment.
For example, in Ubuntu cpufreq-applet not asking password (by default). But if you don't want to input password anymore, there is (at least) two ways (easy way and correct way):
easy way - make /usr/bin/cpufreq-selector binary suid'able by command
# chmod +s /usr/bin/cpufreq-selector
but as you probably know suidable binaries should be as less as possible in system.
So correct way - configure PolicyKit for permit your user to change frequency:

# cat /var/lib/polkit-1/localauthority/50-local.d/org.gnome.cpufreqselector.pkla
[org.gnome.cpufreqselector]
Identity=unix-user:put_your_login_name_here
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes

So, it's not a bug actually, but I agree that such behavior can be pretty annoying.
I guess that I just should add advice about PolicyKit in a FAQ.
Now, please, try a trick with PolicyKit and let me know, if there is still exists some problems with passwords and authentication.

Revision history for this message
Omar Campagne (ocampagne) wrote :

Thanks for the interest on a non-bug :)

The policykit trick just works perfectly. I agree that this is not a bug
(now that you explained), but it'll be nice if the
permissions could be remembered till the end of session....
or just write that trick on a FAQ.

Ivan Zorin (iaz)
Changed in battery-status:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.