[Intrepid] Policykit denies changes to cpu frequency and ultimately leads to distro update failure

[bp]

While updating to Intrepid beta 6, Policykit decided to disregard my GNOME default to always use the powersave CPU governor and went Performance instead. It took me a decent numbers of step to get near to solving this, but as I had foreseen my laptop overheated and died in the middle of the update.

While I raced against the overheating CPU, error messages were mainly unhelpful in troubleshooting the issue.

My first attempt was to use the cpu frequency selector panel tool. It simply failed silently. Then I tried again, and again, and then some more. Then I whipped up the console.

"apropos cpu" showed up the commandline cpufreq-selector, which I tried.

> badp:~$ cpufreq-selector -g powersave
> Error calling SetGovernor: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success

This error message would made a worthy entry to TheDailyWTF.com's Error'ed series, but nevermind that.

I tried to manually set the frequency using the other option:

> badp:~$ cpufreq-selector 798
> Failed to acquire org.gnome.CPUFreqSelector: Connection ":1.1673" is not allowed to own the service "org.gnome.CPUFreqSelector" due to security policies in the configuration file

I rush to the PolicyKit graphical interface, reach org.gnome.CPUFreqSelector and try to allow any user to change it. Clicking on the "Modify..." button, though, is a no-op. Nothing happens. Not an error message, nothing. Again, I get back to my shell, and after some apropos'ing I try:

> badp:~$ polkit-action --set-defaults-any org.gnome.cpufreqselector yes
> polkit-set-default-helper: needs to be setuid polkituser
> Error: code=8: NotAuthorizedToModifyDefaults: uid 1000 is not authorized to modify defaults for implicit authorization for action org.gnome.cpufreqselector (requires org.freedesktop.policykit.modify-defaults)

> badp:~$ sudo polkit-action --set-defaults-any org.freedesktop.policykit.modify-defaults auth_self
> polkit-set-default-helper: needs to be setuid polkituser
> Error: code=8: NotAuthorizedToModifyDefaults: uid 0 is not authorized to modify defaults for implicit authorization for action org.freedesktop.policykit.modify-defaults (requires org.freedesktop.policykit.modify-defaults)

While I try to decode the "needs to be setuid polkituser" line, the computer dies for overheat. Right in the middle of a distro update.

I can now choose between the 2.7 kernel with the blinking caps lock led of death, the old 2.5 kernels which shows helpful information about the mount command syntax but fails to boot, and Windows XP which I'm using to file this bug. I guess the only solution now is a full reinstall.

EDIT: I would like to add that "powersave" was set as the default cpu governor by using the GNOME Configuration Editor tool. Why did PolicyKit decide all of a sudden that all of a member of the admin group, root AND the default settings were wrong?

[bp (badpazzword)]

While updating to Intrepid beta 6, Policykit decided to disregard my GNOME default to always use the powersave CPU governor and went Performance instead. It took me a decent numbers of step to get near to solving this, but as I had foreseen my laptop overheated and died in the middle of the update.

While I raced against the overheating CPU, error messages were mainly unhelpful in troubleshooting the issue.

My first attempt was to use the cpu frequency selector panel tool. It simply failed silently. Then I tried again, and again, and then some more. Then I whipped up the console.

"apropos cpu" showed up the commandline cpufreq-selector, which I tried.

> badp:~$ cpufreq-selector -g powersave
> Error calling SetGovernor: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success

This error message would made a worthy entry to TheDailyWTF.com's Error'ed series, but nevermind that.

I tried to manually set the frequency using the other option:

badp:~$ cpufreq-selector 798
Failed to acquire org.gnome.CPUFreqSelector: Connection ":1.1673" is not allowed to own the service "org.gnome.CPUFreqSelector" due to security policies in the configuration file

I rush to the PolicyKit graphical interface, reach org.gnome.CPUFreqSelector and try to allow any user to change it. Clicking on the "Modify..." button, though, is a no-op. Nothing happens. Not an error message, nothing. Again, I get back to my shell, and after some apropos'ing I try:

badp:~$ polkit-action --set-defaults-any org.gnome.cpufreqselector yes
polkit-set-default-helper: needs to be setuid polkituser
Error: code=8: NotAuthorizedToModifyDefaults: uid 1000 is not authorized to modify defaults for implicit authorization for action org.gnome.cpufreqselector (requires org.freedesktop.policykit.modify-defaults)

badp:~$ sudo polkit-action --set-defaults-any org.freedesktop.policykit.modify-defaults auth_self
polkit-set-default-helper: needs to be setuid polkituser
Error: code=8: NotAuthorizedToModifyDefaults: uid 0 is not authorized to modify defaults for implicit authorization for action org.freedesktop.policykit.modify-defaults (requires org.freedesktop.policykit.modify-defaults)

While I try to decode the "needs to be setuid polkituser" line, the computer dies for overheat. Right in the middle of a distro update.

I can now choose between the 2.7 kernel with the blinking caps lock led of death, the old 2.5 kernels which shows helpful information about the mount command syntax but fails to boot, and Windows XP which I'm using to file this bug. I guess the only solution now is a full reinstall.

[bp (badpazzword)]

I have filed this bug against Policykit, but it also regards the cpu frequency selector plugin, the GNOME policykit interface and cpufreq-selector for showing unhelpful error messages, if any.

I was just 25 minutes away from Intrepid. Sigh.

[James Westby (james-w)]

Hi,

I'm not sure why you consider this a policykit bug, as policykit doesn't select
the CPU scaling governor.

It sounds like many of your problems could have been caused by the fact
that the system was overheating, and so couldn't really be fixed in the software.

Thanks,

James

[James Westby (james-w)]

Hi,

I am closing this report as I don't consider it to be a useful
bug report for you at this point. I am talking to the reporter
in the Ubuntu bug and trying to find the specific problems
that they had. I will forward any more specific bug reports
as needed.

Thanks,

James

[bp (badpazzword)]

It is of course fair to say that my overheating system isn't a software bug.

However:

1. During the setup, the CPU governor was changed for whatever reason. It was not changed to my Powersafe default, nor to Ubuntu's OnDemand default, but to Performance. I concede I don't really know what did this or why, nor it really is a big problem in itself. I could've changed it back -- wasn't it for PolicyKit.

2. Attempts to fix this situtation were met with no or meaningless error messages, some coming for Policykit itself. I hope you will concede that "uid 0 is not authorized to modify defaults for implicit authorization for action org.freedesktop.policykit.modify-defaults (requires org.freedesktop.policykit.modify-defaults)" is a bit... strange error message.

3. PolicyKit denied Root to edit settings. In https://launchpad.net/ubuntu/+source/policykit/0.7-2ubuntu4 it is noted that Root /is/ supposed to have full access to Policykit since Hardy. Change logs for following versions do not highlight changes in this behavior.

I do believe PolicyKit did not behave as designed in this situation. I also believe that many applications need to be changed to recognise failures coming from PolicyKit policies. Feel free to extend this bug to the other involved packages, I could not find any.

[James Westby (james-w)]

On Fri, 2008-09-19 at 06:38 +0000, badpazzword wrote:
> It is of course fair to say that my overheating system isn't a software
> bug.
>
> However:
>
> 1. During the setup, the CPU governor was changed for whatever reason.
> It was not changed to my Powersafe default, nor to Ubuntu's OnDemand
> default, but to Performance. I concede I don't really know what did this
> or why, nor it really is a big problem in itself. I could've changed it
> back -- wasn't it for PolicyKit.

This isn't a policykit bug, so if you wish to try and have it fixed you
should file a bug on the appropriate package, or Ubuntu if you don't
know which, but having a guess at the package would be better.

> 2. Attempts to fix this situtation were met with no or meaningless error
> messages, some coming for Policykit itself. I hope you will concede that
> "uid 0 is not authorized to modify defaults for implicit authorization
> for action org.freedesktop.policykit.modify-defaults (requires
> org.freedesktop.policykit.modify-defaults)" is a bit... strange error
> message.

Yes, it's a strange error message, but it is correct.

> 3. PolicyKit denied Root to edit settings. In
> https://launchpad.net/ubuntu/+source/policykit/0.7-2ubuntu4 it is noted
> that Root /is/ supposed to have full access to Policykit since Hardy.
> Change logs for following versions do not highlight changes in this
> behavior.

It denied root as it couldn't launch the helper due to it not being
setuid polkituser. The file is setuid in the package, and on my system,
so I suspect this was due to your system overheating.

> I do believe PolicyKit did not behave as designed in this situation. I
> also believe that many applications need to be changed to recognise
> failures coming from PolicyKit policies. Feel free to extend this bug to
> the other involved packages, I could not find any.

I don't understand why you say that other applications need to be
changed, but can't list any.

The part of this bug report that appears to be valid is that you found
some of the error messages confusing, is that correct? If so can you
give a complete list of the ones that you would like to see improved,
along with suggestions, and we can look at whether they should be
changed.

Thanks,

James

[James Westby (james-w)]

Oh, and I am going to close your report against policykit. Thanks
for filing a report there, but it doesn't seem that the report
is in a state from which they can do anything at this point. I will
report bugs with them if any more specific problems come out
of our discussion.

Thanks,

James

[bp (badpazzword)]

Fair enough.

Thank you for your time.