Subject: Re: [X2Go-Dev] Bug#459: PolicyKit authentication within apps often fails

From: Mike Gabriel <[email-masked]>
Date: Wed, 20 Aug 2014 09:31:15 +0000

Hi Michael,

On  So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:

> Package: x2goserver
> Version: 4.0.1.13
>
> Notes:
>
> 1. I am not sure if this is a bug in x2goserver, x2goserver-xsession,
> or in nx-libs.
>
> 2. PolicyKit depends on ConsoleKit (and on systemd-logind in
> newer distros.)
>
> 3. The behavior seems to be distro-specific and/or app-specific.
>
> 4. This bug report differs from 458 because PolicyKit authentication
> is being called within an app, not when launching the app. This is
> part of the PolilcyKit architecture: The apps run unprivileged and
> rely on PolicyKit in order to speak to privileged processes that do
> the actual task. For example, in test case 2, gpk-application is
> launched unprivileged. It uses PolicyKit to speak to the PackageKit
> backend, and the PackageKit backend does the package install.
>
> Test system:
> Fedora 20 64-bit
> MATE Desktop 1.6.2.1.fc20 - used for all 3 test cases
> x2goserver 4.0.1.13.2.fc20
> x2goserver-xsession 4.0.1.13.2.fc20
> nxlibs 3.5.0.22.1-fc20
> (This distro uses logind)
> (/usr/libexec/polkit-mate-authentication-agent-1 is launched
> automatically when I login over X2Go. This distro is not affected by
> bug 457)
>
> Test Case 1:
> Steps:
> 1. Launch yumex (from start menu or from console)
> 2. Switch to the yumex's "history" tab on the left..
>
> Expected result:
> A policykit authentication window opens up, I select a user to
> authenticate as (myself or root), enter my password, and then the
> history is populated within yumex.
>
> Here is an image of that policykit authentication window:
> http://imgur.com/JUZTBHo
>
> Actual result:
> The authentication window does not open up and the history is no
> populated. Instead, I get an error message windows. When I click
> "Close" on the window, yumex closes.
>
> Error message:
> Fatal Error: polkit-not-authorized
>
> Could not get polkit autherisation to start backend
>
> Yum Extender will terminate
>
> Here's an image of the error message window
> http://imgur.com/ABYETM0
>
> From the command-line, I can see this output when I select the history tab:
> 15:53:07 : INFO - YUM: Error executing command as another user: Not  
> authorized
> 15:53:14 : INFO - yum backend process is ended
> 15:53:14 : INFO - yum backend process is ended
>
> Test Case 2:
> Steps:
> 1. Launch gpk-application (GNOME "Software Install" AKA "Add/Remove  
> Software")
> 2. Select to install a single package.
> 3. Click "Apply Changes"
>
> Expected result: A policykit authentication window opens up, I select
> a user to authenticate as (myself or root), enter my password, and
> then the package is downloaded & installed (over the course of at
> least a few seconds), during which a progress bar is displayed.
>
> Screenshot:
> http://imgur.com/lLNof08
>
> Actual result:
> The authentication window does not open up. The progress bar for the
> install completes in about 1 second. The package is not installed.
> (Interestingly enough, the package is still selected to be installed,
> but the "Apply Changes" and "cancel" button are hidden. This is a bug
> in gpk-application, it does not know how to handle policykit having an
> error. But this gpk-application bug is besides the point.)
>
> Screenshot:
> http://i.imgur.com/28lCZF5.png
>
> Also, the command-line does not show any relevant output.
>
> Test Case 3:
> Steps:
> 1. Launch virt-manager (AKA "Virtual Machine Manager")
>
> This test case actually passes!
>
> Expected & Actual result:
> A policykit authentication window opens up, I select a user to
> authenticate as (e.g., myself or root), enter my password, and then I
> am connected to the local libvirtd instance and see the VMs running.
>
> Screenshot:
> http://imgur.com/mZSgdMW
>
> Also, the command-line output does not include any details about
> PolicyKit (succeeding.)
>
> Note: Test case 3 fails on CentOS 6.5 64-bit. However, CentOS 6.5
> 64-bit is affected by bug 457, so that precludes running this test
> case.

I just fixed #458 by exporting $XAUTHORITY in x2goruncommand.

Do you have any clue what this issue may be related to? As I don't  
have any of the failing apps on Debian, I cannot reproduce your test  
results right away.

Any hint, if this issues also occurs on Debian?

Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb