Bug 524732 - org.libvirt.manage policy kit denial
org.libvirt.manage policy kit denial
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: PolicyKit-gnome (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 737557
  Show dependency treegraph
 
Reported: 2009-09-21 19:13 EDT by Tom Horsley
Modified: 2011-09-12 10:43 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 737557 (view as bug list)
Environment:
Last Closed: 2009-10-05 10:22:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2009-09-21 19:13:24 EDT
Description of problem:
On fedora 11, when I run virt-manager, it asks me for the root password.
On rawhide when I do the same thing, this happens:

Unable to open connection to hypervisor URI 'qemu:///system':
authentication failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 456, in _try_open
    None], flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed


Version-Release number of selected component (if applicable):
virt-manager-0.8.0-4.fc12.noarch

How reproducible:
every time

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
Tells me it can't connect to libvirtd

Expected results:
Asks for authentication, then connects

Additional info:
I didn't install virtualization initially on this machine, but
later did a yum groupinstall to get it, don't know if that affected
permissions on something or what.
Comment 1 Cole Robinson 2009-09-24 12:15:25 EDT
Are you using ssh -X or su to change user? I have the same problem if I 'su - <user>' as another regular user. It's probably some PolicyKit quirk.
Comment 2 Tom Horsley 2009-09-24 12:28:54 EDT
Nope, I just login to gnome session as standard user and run virt-manager
from the system tools menu, and instead of getting an authentication
prompt, I get the error.

If I open a terminal and run:

sudo su -l
virt-manager

that copy of virt-manager works fine (and doesn't ask for any credentials).
Comment 3 Mark McLoughlin 2009-10-02 09:28:35 EDT
Hmm, is this still happening?

How about if, from a non-root terminal in the desktop session, you do:

  $> virsh -c qemu:///system list --all

you should get a dialog asking for the root password and the command should succeed.

With virt-manager, once you've entered the root password, libvirtd runs the pkcheck program to check if the virt-manager pid is authorized

Do you see anything in /var/log/messages when the virt-manager error occurs?
Comment 4 Tom Horsley 2009-10-02 09:46:20 EDT
I made a brand new user just to make sure no junk was laying around in ~/
to cause this problem, and both the virsh command above and running
virt-manager from the menus works fine, I get the login prompt, so it has
either been fixed, or something is screwed up for my original user.
Comment 5 Tom Horsley 2009-10-02 09:50:51 EDT
Back as my original user, it still screws up, and I see this appear
in /var/log/messages:

Oct  2 09:48:11 zooty libvirtd: 09:48:11.300: error : remoteDispatchAuthPolkit:3168 : Policy kit denied action org.libvirt.unix.manage from pid 4136, uid 500, result: 512#012

No sure what I've done to this user, but I'll be re-installing from scratch
with the beta comes out, so it will probably get fixed then.
Comment 6 Mark McLoughlin 2009-10-02 10:25:21 EDT
Okay, I assume this happens with virsh too? Moving to libvirt, in that case

We should figure out what's going on here before you delete that account

davidz, danpb: any ideas for debugging this?
Comment 7 Tom Horsley 2009-10-02 11:03:53 EDT
Yep, virsh also does not work.

Just a random wild theory: Are there things like policykit hooks that get run
when setting up a new account? I did not have any of the Virtualization
packages install at the time the initial account was created. I did
a "yum groupinstall" much later to get the virt stuff for testing.
Comment 8 Tom Horsley 2009-10-04 14:33:52 EDT
I bet it has something to do with the startup app PolicyKit Authentication Agent not existing in the list of startup apps for the user where this isn't working.
Comment 9 Daniel Berrange 2009-10-05 05:03:04 EDT
Yeah previously this auth agent would start on demand, since the client app was responsible to launching it. With new policykit it is expected to be running all the time, since the policykit backend talks directly to it, bypassing the client app. So if its not in your startup apps that'd be the problem.
Comment 10 Mark McLoughlin 2009-10-05 05:48:13 EDT
Tom, you said that when you start virt-manager a dialog pops up asking for the root password? Is that still the case? I thought it was the PolicyKit Authentication Agent that did that?
Comment 11 Tom Horsley 2009-10-05 07:27:53 EDT
I get the dialog on fedora 11, not fedora 12 (at least not fedora 12
when logged in as the user missing the policykit daemon).

P.S. I can't imagine why it is a good idea to require yet another stoopid
gnome daemon to be running all the time just so it will be able to ask
a question maybe once a day (pretty soon you are gonna have to change
linux to use 64 integers for PIDs just so gnome can run :-).
Comment 12 Mark McLoughlin 2009-10-05 07:38:08 EDT
(In reply to comment #11)
> I get the dialog on fedora 11, not fedora 12

Cool, the missing agent explains it then; moving to policy kit

davidz: does the agent get enabled for existing users if you update from F-11 to F-12?
Comment 13 Matthias Clasen 2009-10-05 10:04:59 EDT
polkit-gnome provides/obosoletes PolicyKit-gnome and 
polkit-gnome installs /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

so: yes, existing users should get the agent enabled.
Comment 14 Mark McLoughlin 2009-10-05 10:22:25 EDT
Cool, let's assume this is some random screwup then. Closing as WORKSFORME

Note You need to log in before you can comment on or make changes to this bug.