X2Go Bug report logs - #459
PolicyKit authentication within apps often fails

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: submit@bugs.x2go.org

Subject: PolicyKit authentication within apps often fails

Date: Sun, 23 Mar 2014 12:25:58 -0400

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.

Message #10 received at 459@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Michael DePaulo <mikedep333@gmail.com>, 459@bugs.x2go.org

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

Date: Wed, 20 Aug 2014 09:31:15 +0000

[Message part 1 (text/plain, inline)]

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: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

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

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 459@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

Cc: 459@bugs.x2go.org

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

Date: Wed, 20 Aug 2014 10:04:03 -0400

On Wed, Aug 20, 2014 at 5:31 AM, Mike Gabriel
<mike.gabriel@das-netzwerkteam.de> wrote:
> Hi Michael,
>
>
> On  So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:
>
>>[...]
>
>
> I just fixed #458 by exporting $XAUTHORITY in x2goruncommand.

Thank you :)

> 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.

2 possible theories:
1. We are not integrating with ConsoleKit and/or logind properly.
(Although it appears that our integration with logind is better, since
Fedora 20 works better than CentOS 6.)
2. We have issues with the polcykit authentication windows not being
permitted to show up.

I think that there is different behavior when using XDMCP. I'll double
check after work.

Also, Red Hat has some KB articles on this subject. I noticed them
after I bought a RHEL subscription for home. I'll look over them
again, and update this bug with any relevant info.

> Any hint, if this issues also occurs on Debian?

I can test this with VMs. I've already created some Debian VMs for
compatibility testing with X2Go. Which of the 3 releases (squeeze,
wheezy and jessie) should I test? Squeeze is similar to CentOS 6 in
terms of versions of packages like ConsoleKit.

> Mike
[...]

Message #20 received at 459@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>, 459@bugs.x2go.org

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

Date: Wed, 20 Aug 2014 10:14:34 -0400

On Wed, Aug 20, 2014 at 10:04 AM, Michael DePaulo <mikedep333@gmail.com> wrote:
> On Wed, Aug 20, 2014 at 5:31 AM, Mike Gabriel
> <mike.gabriel@das-netzwerkteam.de> wrote:
>> Hi Michael,
>>
>>
>> On  So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:
>>
>>>[...]
>>
>>
>> I just fixed #458 by exporting $XAUTHORITY in x2goruncommand.
>
> Thank you :)
>
>> 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.
>
> 2 possible theories:
> 1. We are not integrating with ConsoleKit and/or logind properly.
> (Although it appears that our integration with logind is better, since
> Fedora 20 works better than CentOS 6.)
> 2. We have issues with the polcykit authentication windows not being
> permitted to show up.
>
A 3rd possible theory:
3. PolicyKit policies are blocking certain actions from happening over
any sort of remote session. PolicyKit refers to local sessions as
"Active" and remote sessions as "Inactive".
It appears that the X11RDP project has run into this problem:
http://scarygliders.net/2012/06/20/a-brief-guide-to-policykit/
http://scarygliders.net/category/policykit/

> I think that there is different behavior when using XDMCP. I'll double
> check after work.
>
> Also, Red Hat has some KB articles on this subject. I noticed them
> after I bought a RHEL subscription for home. I'll look over them
> again, and update this bug with any relevant info.
>
>> Any hint, if this issues also occurs on Debian?
>
> I can test this with VMs. I've already created some Debian VMs for
> compatibility testing with X2Go. Which of the 3 releases (squeeze,
> wheezy and jessie) should I test? Squeeze is similar to CentOS 6 in
> terms of versions of packages like ConsoleKit.
>
>> Mike
> [...]

Message #25 received at 459@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Michael DePaulo <mikedep333@gmail.com>

Cc: 459@bugs.x2go.org

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

Date: Fri, 22 Aug 2014 21:30:08 +0000

[Message part 1 (text/plain, inline)]

On  Mi 20 Aug 2014 16:04:03 CEST, Michael DePaulo wrote:

> On Wed, Aug 20, 2014 at 5:31 AM, Mike Gabriel
> <mike.gabriel@das-netzwerkteam.de> wrote:
>> Hi Michael,
>>
>>
>> On  So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:
>>
>>> [...]
>>
>>
>> I just fixed #458 by exporting $XAUTHORITY in x2goruncommand.
>
> Thank you :)
>
>> 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.
>
> 2 possible theories:
> 1. We are not integrating with ConsoleKit and/or logind properly.
> (Although it appears that our integration with logind is better, since
> Fedora 20 works better than CentOS 6.)

On Debian systems all is handled via the /etc/X11/Xsession.d directory.

For RHEL et al I see this in the /etc/x2go/Xsession script:

"""
        CK_XINIT_SESSION=
        if [ -x /usr/bin/ck-xinit-session -a -z "$XDG_SESSION_COOKIE" ]; then
                CK_XINIT_SESSION="/usr/bin/ck-xinit-session"
        fi

        # At the time of integrating X2Go Xsession support for RHEL6 / Fedora
        # the Xsession stuff in Fedora/RHEL6 seems to be a little mess.
        # The proposed strategy is to have Xclients.$WM.sh files in
        # /etc/X11/xinit/Xclients.d. Currently, only wmx uses this mechanism.
        # As it is a described but rather unused ,,standard'' we will  
not support it
        # in X2Go for now, but leave it here as a reminder...

        # XCLIENTS_D=/etc/x2go/Xclients.d
        #if [ -d "$XCLIENTS_D" -a -x  
"$XCLIENTS_D/Xclients.${XSESSION_EXEC}.sh" ]; then
        #       exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT  
$XCLIENTS_D/Xclients.$1.sh"
        #fi

        # switchdesk support is also totally deprecated in RHEL, but  
we leave it here
        # as a reminder, as well, in case we need it in the future  
for special setups...
        #if [ -x "$SWITCHDESKPATH/Xclients.${XSESSION_EXEC}" ]; then
        #       exec -l "$SHELL" -c  
"$SWITCHDESKPATH/Xclients.${XSESSION_EXEC}";
        #fi

        exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL  
-c \"$STARTUP\""
"""

It has been derived from the X11 session startup on SL6. Maybe we need  
to tweak this CK_XINIT_SESSION variable and change over to using  
ck-launch-session here.

Maybe this is hint enough for you to play with this some more.?...

> 2. We have issues with the polcykit authentication windows not being
> permitted to show up.
>
> I think that there is different behavior when using XDMCP. I'll double
> check after work.

Ok. Any results?

> Also, Red Hat has some KB articles on this subject. I noticed them
> after I bought a RHEL subscription for home. I'll look over them
> again, and update this bug with any relevant info.
>
>> Any hint, if this issues also occurs on Debian?
>
> I can test this with VMs. I've already created some Debian VMs for
> compatibility testing with X2Go. Which of the 3 releases (squeeze,
> wheezy and jessie) should I test? Squeeze is similar to CentOS 6 in
> terms of versions of packages like ConsoleKit.

squeeze has CK and GNOMEv2, wheezy has CK and XFCE or GNOMEv3...
jessie has systemd and MATE, GNOMEv3, etc.

So I guess, you should stick with wheezy for CK testing and use jessie  
for systemd testing.

Mike#1

-- 

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

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

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

[Message part 2 (application/pgp-signature, inline)]

Message #30 received at 459@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Michael DePaulo <mikedep333@gmail.com>

Cc: 459@bugs.x2go.org

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

Date: Fri, 22 Aug 2014 21:33:39 +0000

[Message part 1 (text/plain, inline)]

On  Mi 20 Aug 2014 16:14:34 CEST, Michael DePaulo wrote:

> On Wed, Aug 20, 2014 at 10:04 AM, Michael DePaulo  
> <mikedep333@gmail.com> wrote:
>> On Wed, Aug 20, 2014 at 5:31 AM, Mike Gabriel
>> <mike.gabriel@das-netzwerkteam.de> wrote:
>>> Hi Michael,
>>>
>>>
>>> On  So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:
>>>
>>>> [...]
>>>
>>>
>>> I just fixed #458 by exporting $XAUTHORITY in x2goruncommand.
>>
>> Thank you :)
>>
>>> 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.
>>
>> 2 possible theories:
>> 1. We are not integrating with ConsoleKit and/or logind properly.
>> (Although it appears that our integration with logind is better, since
>> Fedora 20 works better than CentOS 6.)
>> 2. We have issues with the polcykit authentication windows not being
>> permitted to show up.
>>
> A 3rd possible theory:
> 3. PolicyKit policies are blocking certain actions from happening over
> any sort of remote session. PolicyKit refers to local sessions as
> "Active" and remote sessions as "Inactive".
> It appears that the X11RDP project has run into this problem:
> http://scarygliders.net/2012/06/20/a-brief-guide-to-policykit/
> http://scarygliders.net/category/policykit/
>

I stumbled over this the other day, when I was going through these  
polkit bugs, myself.

We don't want X2Go sessions to be "active=TRUE" and neither do we want  
them to be local.

Sessions are marked as active and local sessions if the user is really  
sitting in front of a machine. Those session will accept USB  
flashdrives when they are plugged into the workstation. We want that  
with local X.org sessions, but not in X2Go sessions.

Greets,
Mike
-- 

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

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

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

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.