Bug 795978

I'm not sure if only libvirt is at fault, or even if the reported problem would occur on RHEL or is just specific to Fedora rawhide, but it cannot hurt to backport the libvirt patches related to polkit authorization.

In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-February/msg01033.html

(In reply to comment #3)
> In POST:
> http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-February/msg01033.html

Hi Eric,
Should I follow progress at the above url?

(In reply to comment #4)
> (In reply to comment #3)
> > In POST:
> > http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-February/msg01033.html
> 
> Hi Eric,
> Should I follow progress at the above url?

That depends - are you interested in what gets built for RHEL 6.3 (that URL provides the patch for backporting the fix to RHEL), or are you interested in what gets built for rawhide (in which case, bug 790037 is the one to follow), or are you interested in building your own libvirt (in which case, libvirt.git has already been patched, and libvirt 0.9.11 will have the fix)?

With libvirt-0.9.10-0rc2.el6.x86_64, reproduce this problem.
Steps:
1. enable dbus.service
# /etc/rc.d/init.d/messagebus start
Starting system message bus:                               [  OK  ]
2. enable avahi-daemon.service
# /etc/init.d/avahi-daemon start
Starting Avahi daemon...                                   [  OK  ]
3. start libvirtd.service
# /etc/init.d/libvirtd start
Starting libvirtd daemon:                                  [  OK  ]
4. Switch to regular user and connect to libvirtd
$ virsh --connect qemu:///system
error: authentication failed: Authorization requires authentication but no
agent is available.

error: failed to connect to the hypervisor

Tested fail with libvirt-0.9.10-3.el6.x86_64.
Note, 
The test steps like comment 6 described.
If i run 'virt-manager' or 'virsh -c qemu:///system' as regular user locally, the Authenticate message box will popup and ask for root password, that works correctly. 
But if i run these commands over ssh -X as regular user, it still failed.
The libvirtd log as following:
# tail -f /var/log/libvirt/libvirtd.log
2012-02-29 07:59:37.412+0000: 2320: error : remoteDispatchAuthPolkit:2525 : Policy kit denied action org.libvirt.unix.manage from pid 3085, uid 500: exit status 2
2012-02-29 07:59:37.412+0000: 2320: error : remoteDispatchAuthPolkit:2554 : authentication failed: Authorization requires authentication but no agent is available.

2012-02-29 07:59:41.946+0000: 2318: error : virNetSocketReadWire:999 : End of file while reading data: Input/output error

Is there anything i missed to test this bug? please correct me, thanks!

PolicyKit is unable to prompt for any passwords if you're running from an SSH shell.  If you want that to work, you'd have to change the local policy to *not* ask for a password in this scenario.  Only if running from a desktop login session directly will it ask for passwords.

I'm not sure the best way to test this, but the way I found that a patch needed backporting in the first place was by running libvirtd under valgrind, then using virt-manager to connect to libvirt.  Before the patch, there was a memory leak on stock 0.9.10 usage, pointing back to the polkit code.

(In reply to comment #13)
> (In reply to comment #12)
> > Hi,
> >   I'm trying to reproduce this bug(polkit authorization broken). But still
> > can't find the root problem.
> 
> > 
> > I'm not sure what the exact test/verify steps should be, so please correct me
> > if needed. Thanks!
> 
> See comment #11.  I also don't know how to demonstrate the real problem by use
> of polkit policy files.  I only know that I found the issue by using valgrind
> on a default installation, with no modification of polkit files, and verified
> that the patch was able to plug the leak reported by valgrind.

Then this bug can be verified. Both on libvirt-0.9.10-3.el6.x86_64 and libvirt-0.9.10-16.el6.x86_64.
With libvirt-0.9.10-1.el6.x86_64 
use valgrind to check libvirtd, result like:
==17288== LEAK SUMMARY:
==17288==    definitely lost: 738 bytes in 40 blocks
==17288==    indirectly lost: 0 bytes in 0 blocks
==17288==      possibly lost: 8,664 bytes in 50 blocks
==17288==    still reachable: 1,933,261 bytes in 19,248 blocks
==17288==         suppressed: 0 bytes in 0 blocks
==17288== Rerun with --leak-check=full to see details of leaked memory
==17288== 
==17288== For counts of detected and suppressed errors, rerun with: -v
==17288== Use --track-origins=yes to see where uninitialised values come from
==17288== ERROR SUMMARY: 85 errors from 15 contexts (suppressed: 32 from 9)
After upgrade libvirt, result like:
==19445== LEAK SUMMARY:
==19445==    definitely lost: 0 bytes in 0 blocks
==19445==    indirectly lost: 0 bytes in 0 blocks
==19445==      possibly lost: 0 bytes in 0 blocks
==19445==    still reachable: 126,299 bytes in 1,346 blocks
==19445==         suppressed: 0 bytes in 0 blocks
==19445== Rerun with --leak-check=full to see details of leaked memory
==19445==
==19445== For counts of detected and suppressed errors, rerun with: -v
==19445== Use --track-origins=yes to see where uninitialised values come from
==19445== ERROR SUMMARY: 45 errors from 10 contexts (suppressed: 8 from 6)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html