Package: x2goserver Version: 4.0.1.13
Notes:
I am not sure if this is a bug in x2goserver, x2goserver-xsession, or in nx-libs.
PolicyKit depends on ConsoleKit (and on systemd-logind in newer distros.)
The behavior seems to be distro-specific and/or app-specific.
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:
- Launch yumex (from start menu or from console)
- 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:
- Launch gpk-application (GNOME "Software Install" AKA "Add/Remove Software")
- Select to install a single package.
- 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:
- 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.
Hi Michael,
On So 23 Mär 2014 17:25:58 CET, Michael DePaulo wrote:
Package: x2goserver Version: 4.0.1.13
Notes:
I am not sure if this is a bug in x2goserver, x2goserver-xsession, or in nx-libs.
PolicyKit depends on ConsoleKit (and on systemd-logind in newer distros.)
The behavior seems to be distro-specific and/or app-specific.
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:
- Launch yumex (from start menu or from console)
- 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 endedTest Case 2: Steps:
- Launch gpk-application (GNOME "Software Install" AKA "Add/Remove
Software")- Select to install a single package.
- 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:
- 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.xf...
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: permitted to show up.
- 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.)
- We have issues with the polcykit authentication windows not being
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 [...]
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: permitted to show up.
- 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.)
- We have issues with the polcykit authentication windows not being
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 [...]
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: permitted to show up.
- 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.)
- We have issues with the polcykit authentication windows not being
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.xf...
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:
- 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.?...
- 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.xf...
-
Michael DePaulo -
Mike Gabriel