Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP

Bug #221363 reported by volksman
246
This bug affects 30 people
Affects Status Importance Assigned to Milestone
FreeNX Server
Fix Released
Medium
Unassigned
PolicyKit
Invalid
Critical
gdm
Expired
Medium
system-tools-backends
Fix Released
Undecided
Unassigned
ltsp (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Hardy by gozotto
Nominated for Lucid by Jakob Unterwurzacher
policykit (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Hardy by gozotto
Nominated for Lucid by Jakob Unterwurzacher
policykit-1 (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Hardy by gozotto
Nominated for Lucid by Jakob Unterwurzacher
system-tools-backends (Ubuntu)
Triaged
Medium
Unassigned
Nominated for Hardy by gozotto
Nominated for Lucid by Jakob Unterwurzacher

Bug Description

I installed 8.04 LTS server on a system. Then installed ubuntu-desktop using apt. Installed Nomachine's NX server and connected to it.

The unlock buttons on Users and Groups or Network are greyed out and un-accessible. Tried running from a term 'sudo users-admin' with the same results.

Works fine with VNC and NX "Shadow" session however this is not really acceptable as it means a session has to be running on console first.

I have tried to enable every option in Authorizations to allow the remote session to have privileges to no avail.

output of dpkg relevant packages:

ii gnome-system-t 2.22.0-0ubuntu Cross-platform configuration utilities for G
ii liboobs-1-4 2.22.0-0ubuntu GObject based interface to system-tools-back
ii policykit 0.7-2ubuntu7 framework for managing administrative polici
ii system-tools-b 2.6.0-0ubuntu7 System Tools to manage computer configuratio

================
== Workarounds ==
================

1) *Jaunty or older*

From https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/238799/comments/16 (the packages from comment 24 are broken links now):

I was able to get access via VNC tunneled through SSH by changing the following settings in policykit. You can do it locally via Authorizations, or you can do it remotely using "sudo ck-launch-session polkit-gnome-authorization" in a terminal window in your tunneled VNC session. This worked on Ubuntu 9.04 Server RC running xubuntu-desktop, so as always YMMV.

For system configuration, change all implicit authorizations under org -> freedesktop -> systemtoolsbackends -> Manage System Configuration (org.freedesktop.systemtoolsbackends.set) to "Admin Authentication."

For user management, change all implicit authorizations under org -> freedesktop -> systemtoolsbackends -> self -> Change User Configuration (org.freedesktop.systemtoolsbackends.self.set) to "Authentication."

Reset gdm by rebooting or running "sudo /etc/init.d/gdm restart" from a terminal window, and you should be able to unlock the user settings control panel and other similarly useful things through your tunneled VNC session.

2) *Karmic or newer*

Apply this patch: http://launchpadlibrarian.net/39471473/polkit-systemtools-remote-allow.patch
# sudo cp -a /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy.ori
# sudo patch /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy polkit-systemtools-remote-allow.patch

Then kill polkitd, it will be restarted automatically:
# sudo pkill polkitd

Revision history for this message
volksman (v0lksman69) wrote :

Sorry...Forgot to mention I had a similar issue with another system built the same way. Server install first and added xorg and gnome (not the ubuntu-desktop meta package) after the fact and it wouldn't let me unlock any admin apps.

Revision history for this message
volksman (v0lksman69) wrote :

Please close. n00b error. I was connected remotely via NX.

Revision history for this message
Craig Younkins (cyounkins) wrote :

Why is this a "n00b error"?

There are a whole people here ( http://ubuntuforums.org/showthread.php?p=4801691 ) having the same problem with NX server. What can we do to get policykit to work for NX users?

Revision history for this message
volksman (v0lksman69) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

Please disregard first two comments. I had originally filed this bug as a bug with policykit not working at all before I realized that NX could be interfering.

This has been confirmed by a number of people in the forums: http://ubuntuforums.org/showthread.php?t=712006

description: updated
Revision history for this message
Guenter (ubuntu-linux-stueck) wrote :

Please let me note that I'm interested in a solution for this problem, too.

Revision history for this message
paulsdavies (paul-s-davies) wrote :

I am having this problem too.

Revision history for this message
gozotto (webmaster-machard) wrote :

Please let me know if a fix is available.

Revision history for this message
In , Marcelo Boveto Shima (marceloshima) wrote :

There is no way to grant an action to an user if the running session is defined with is-local=false on ConsoleKit. I am integrating FreeNX with ConsoleKit/PolicyKit and would be nice to allow actions on a local console and deny on a remote console, and allow to do it on a remote console if configured to do so.

Revision history for this message
houstonbofh (leesharp) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

This problem also occurs when you use 'ssh -X' and try and run 'users-admin' for example. There is no way to admin a Hardy system via ssh using the GUI tools.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

I just made a way to make it work.
The problem is that PolicyKit verify if you are on a valid/local/active ConsoleKit session.
To correct the problem follow this steps:
 - Copy nx-session-launcher and nx-session-launcher-suid to /usr/bin
 - Execute $ chown nx /usr/bin/nx-session-launcher-suid
 - Execute $ chmod 4755 /usr/bin/nx-session-launcher-suid
 - Copy ConsoleKit-NX.conf to /etc/dbus-1/system.d/
 - Edit /etc/nxserver/node.conf and change '#COMMAND_START_GNOME=gnome-session'
     to 'COMMAND_START_GNOME=/usr/bin/nx-session-launcher-suid gnome-session'

If anyone uses my ppa I just uploaded to intrepid to test (intrepid package should work fine on hardy).
I will copy to hardy in a day or 2.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :
Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :
Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

Forgot to mention that the dbus daemon need to reload the configs by executing:
$ /etc/init.d/dbus reload

Revision history for this message
volksman (v0lksman69) wrote :

@Marcelo: I don't have a /etc/nxserver/node.conf. Did a search and node.conf is not found on my system at all.

Any ideas?

Revision history for this message
volksman (v0lksman69) wrote :

@Marcelo: Just realized you fixed FreeNX. Not nomachines NX. Wonder if I should switch. I tried to change Nomachines nxnode config to use your nx-session-launcher but it doesn't work, just crashes.

Are you confirming this is a problem with NX though and not policy kit or is this a band-aid until policy kit is fixed? I'm not sure anyone has opened a bug with Nomachine yet for this issue.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

Do you use any package or is built from scrap?
Try to change this line on the file /usr/bin/nxloadconfig

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

Try to chance the session configuration on nxclient to unix-custom instead of unix-gnome.
In application put /usr/bin/nx-session-launcher-suid on 'run the following command' and 'New virtual desktop' on options

Or maybe there is a configuration file on /usr/NX/etc

Revision history for this message
volksman (v0lksman69) wrote :

Tried with both:

edit /usr/NX/etc/node.cfg and add /usr/bin/nx-session-launcher to the COMMAND directive. NX crashes on connect.

changed my client profile to custom and added /usr/bin/nx-session-launcher-suid as the launched application and NX doesn't crash but no desktop is drawn. Just the NX window.

Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX

volksman wrote:
> @Marcelo: Just realized you fixed FreeNX. Not nomachines NX. Wonder
> if I should switch. I tried to change Nomachines nxnode config to use
> your nx-session-launcher but it doesn't work, just crashes.
>
> Are you confirming this is a problem with NX though and not policy kit
> or is this a band-aid until policy kit is fixed? I'm not sure anyone
> has opened a bug with Nomachine yet for this issue.

The point of my post was that this problem occurs when there is no NX at
all, but in SSH as well. So the problem appears to be that when you are
not directly at the console, policykit totally locks down.

Revision history for this message
volksman (v0lksman69) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

True enough. So the problem is really with PolicyKit and Marcelo's fix is a band-aid for FreeNX.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

The problem with PolicyKit is that it don't alow a remote session to have privileges.
I already filled a bug while hacking the solution at https://bugs.freedesktop.org/show_bug.cgi?id=16510.

SSH creates a remote session. NX don't creates a session (my solution creates a
session on ConsoleKit, set active and set local).

To PolicyKit work you must have to be in a valid ConsoleKit session. ConsoleKit uses
the environment variable XDG_SESSION_COOKIE like:

$ echo $XDG_SESSION_COOKIE
f493e0b30e554108c3114c0046ffd1d0-1214412029.846197-1968504223

You can see ConsoleKit sessions executing:

$ ck-list-sessions
Session1:
 uid = '1000'
 realname = 'Marcelo,,,'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2008-06-25T16:40:29Z'

So if you don't set a active=TRUE and is-local=TRUE session on ConsoleKit
PolicyKit won't work.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

A proof of concept, you can try it on a NX session:

convidado@laptop:~$ ck-list-sessions
Session1:
 uid = '1000'
 realname = 'Marcelo Boveto Shima,,,'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2008-06-25T16:40:29Z'

convidado@laptop:~$ nx-session-launcher-suid ck-list-sessions
Session1:
 uid = '1000'
 realname = 'Marcelo,,,'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2008-06-25T16:40:29Z'
Session3:
 uid = '1001'
 realname = 'Convidado,,,,'
 seat = 'Seat3'
 session-type = 'nx'
 active = TRUE
 x11-display = ':1000.0'
 x11-display-device = ''
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2008-06-25T17:07:12Z'

convidado@laptop:~$ nx-session-launcher-suid users-admin

How it works?
 - $ ck-list-sessions
        shows my X session
 - $ nx-session-launcher-suid ck-list-sessions
        nx-session-launcher-suid creates a session, then executes ck-list-sessions and the session ends
 - $ nx-session-launcher-suid users-admin
        nx-session-launcher-suid creates a session, then executes users-admin and the session ends
        The PolicyKit button is not grayed

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

I forgot to tell that ck-session launcher is compiled for i386.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

I've created a package to be used with NX Free edition.

But you have to edit /usr/NX/etc/node.cfg and change:
 - CommandStartGnome="/usr/bin/dbus-launch --exit-with-session gnome-session"
to
 - CommandStartGnome="nx-session-launcher-suid gnome-session"

The package is in the building queue, once it finish I will post the location here.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :
Revision history for this message
volksman (v0lksman69) wrote :

After installing the above package and making the change to /usr/NX/etc/node.cfg I am able to use PolicyKit remotely.

Nicely done Marcelo!

Revision history for this message
Zdeněk Dlauhý (zdlauhy) wrote :

I think that must be repaired in the PolicyKit, not in the NX/FreeNX/SSH....

Revision history for this message
Zdeněk Dlauhý (zdlauhy) wrote :

But i will try it...:)

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote :

Indeed, PolicyKit should be repaired to allow a remote sessions permission to do something.
But FreeNX/NX must be fixed to create a valid session.

My solution corrects FreeNX/NX but just workaround PolicyKit problem.

But I must say that in some cases this solution has a SECURITY IMPLICATION.
Like I've showed in the proof of concept, the solution can act like a "sudo" and
sudo my itself is an workaround.
The problem is that a remote session should have the permission to gain admin
right only if it is explicitly allow to do so.

This happens only if you have admin rights but don't have "sudo" permission.
Don't apply to Ubuntu, since the admin group has sudo permission by default.
But I think Fedora/Red Hat don't uses "sudo" by default.

Everybody that uses this fix must be aware of this problem.

Revision history for this message
eye.zak (eye-zak) wrote :

Check how Authorizations uses policy kit, you should be able to authenticate with NX. (Authorizations came from policykit). Maybe users-admin and network-admin need to do things differently.

Changed in freenx:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote : Re: [Bug 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX

On Sat, Jul 26, 2008 at 4:57 PM, eye.zak <email address hidden> wrote:

> Check how Authorizations uses policy kit, you should be able to
> authenticate with NX. (Authorizations came from policykit). Maybe
> users-admin and network-admin need to do things differently.
>

This error has already has been triaged and an workaround is available.

If you are using NX from NOMACHINE:
 - Install package from #24
 - Follow instruction from #23

if you are using FreeNX:
 - Install package from #24
 - Edit /etc/nxserver/node.conf and change
'#COMMAND_START_GNOME=gnome-session'
     to 'COMMAND_START_GNOME=/usr/bin/nx-session-launcher-suid
gnome-session'

Thanks

Changed in policykit:
status: Unknown → Confirmed
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

closing Ubuntu task

description: updated
Revision history for this message
James Westby (james-w) wrote :

Hi,

Please don't close the Ubuntu task, this is still a problem with
Ubuntu.

Thanks,

James

description: updated
description: updated
Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX

Marcelo Boveto Shima wrote:
> ** Description changed:
>
> I installed 8.04 LTS server on a system. Then installed ubuntu-desktop
> using apt. Installed Nomachine's NX server and connected to it.
>
> The unlock buttons on Users and Groups or Network are greyed out and un-
> accessible. Tried running from a term 'sudo users-admin' with the same
> results.
>
> Works fine with VNC and NX "Shadow" session however this is not really
> acceptable as it means a session has to be running on console first.

I would love to change the description removing NX entirly. This also
happens when using 'ssh -X' to access a system. There is not way to
remotely admin a system using GUI tools without having an open console.
(Which may have an unprivileged user sitting at it...) This bug is a
show stopper for me, and one reason I am holding at Gutsy.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

Closing the FreeNX task, it is fixed in FreeNX 0.7.3

Changed in freenx-server:
status: Triaged → Fix Released
Revision history for this message
robled (robled) wrote :

Was using Marcelo's workaround until I upgraded the system in question to Intrepid. I could not create a new session after upgrading. The nomachine client would display a black screen and then immediately exit after logging in. I have reverted back to the old node.cfg until an Intrepid-compatible workaround can be found.

Revision history for this message
Marcelo Boveto Shima (marceloshima) wrote : Re: [Bug 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX

I supposing you are using NoMachine NX Free edition.
So add the repository:
deb http://ppa.launchpad.net/freenx-team/ubuntu intrepid main

And use the freenx-session-launcher from this repository.

On Mon, Nov 3, 2008 at 8:34 PM, NTolerance <email address hidden> wrote:

> Was using Marcelo's workaround until I upgraded the system in question
> to Intrepid. I could not create a new session after upgrading. The
> nomachine client would display a black screen and then immediately exit
> after logging in. I have reverted back to the old node.cfg until an
> Intrepid-compatible workaround can be found.
>
>

Revision history for this message
schnollk (schnollk) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

For SSH sessions I'd like to add that the error still persists here. Nastyly it's happening for me on a laptop with broken display that I use as a "server" (no graphical login). So I'm -- among others -- not able to add users or change time.

While reading here I couldn't find a solution that would let me use users-admin without a display, i.e. graphilcal login?

Just now I noticed this message while fireing up users-admin sudoed:

** (users-admin:26835): CRITICAL **: Unable to lookup session information for process '26835'

Cheers!

Revision history for this message
foodbag (food-bag) wrote :

I'm using the NX Free Edition Server on Intrepid, and when I try to install the latest freenx-session-launcher from the repository, it errors out. The older deb package installs, but I get the black screen when trying to create a new session.

Revision history for this message
Monkberry (peter-monkberry) wrote :

Nice fix Marcelo, worked great for me!

Revision history for this message
sudopod (constantinexiii) wrote :

https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/238799/comments/16

Note: This should work, but be cautious as it does change the security policy from the default. Use only if you have trustworthy remote users.

description: updated
Revision history for this message
In , Zeuthen (zeuthen) wrote :

This bug report is for the old version of PolicyKit. Closing as all of the code has been rewritten. Please reopen if the bug report applies to the latest version of PolicyKit. Thanks.

Changed in policykit:
status: Confirmed → Invalid
description: updated
description: updated
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : Re: Policy Kit Unlock Buttons Greyed Out when using NX

Attached patch enables remote users to unlock the dialog.

Apply the patch:

sudo cp -a /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy.ori
sudo patch /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy polkit-systemtools-remote-allow.patch

description: updated
description: updated
tags: added: patch
Anzenketh (anzenketh)
Changed in policykit-1 (Ubuntu):
status: New → Confirmed
Changed in policykit (Ubuntu):
status: New → Confirmed
summary: - Policy Kit Unlock Buttons Greyed Out when using NX
+ Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Patch tested by another LTSP User: http://thread.gmane.org/gmane.linux.terminal-server.general/27584/focus=27651

So the question is: Is it clever to disallow remote sessions to use the GUI admin tools. What's the point? Members of the admin group can sudo -s anyway.
At least the LTSP packages should ship some change to that policy.

Revision history for this message
houstonbofh (leesharp) wrote :

You forgot to add "ssh -X" to the title. Yes, it is a bad decision, in my opinion.

Revision history for this message
Stefano Rivera (stefanor) wrote :

Unsubscribing ubuntu-sponsors, as this isn't ready for sponsorship yet, we need some debdiffs.

https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue

Revision history for this message
In , healthly (healthly) wrote :

There is no way to grant an action to an user if the running session is defined
with is-local=false on ConsoleKit. I use ubuntu 10.04 amd64.I am integrating vnc with
ConsoleKit/PolicyKit and would be nice to allow actions on a local console and
deny on a remote console, and allow to do it on a remote console if configured
to do so.

Revision history for this message
In , Zeuthen (zeuthen) wrote :

(In reply to comment #2)
> There is no way to grant an action to an user if the running session is defined
> with is-local=false on ConsoleKit. I use ubuntu 10.04 amd64.I am integrating
> vnc with
> ConsoleKit/PolicyKit and would be nice to allow actions on a local console and
> deny on a remote console, and allow to do it on a remote console if configured
> to do so.

Yes there is a way to do this. It's called <allow_any>.

Revision history for this message
In , healthly (healthly) wrote :

Thank you verymuch!

Changed in policykit:
importance: Unknown → Critical
Revision history for this message
Razvan Cosma (rg-cosma) wrote :

Using polkit-gnome-authorization doesn't work for me (it only displayes the org.freedesktop.policykit tree), neither does editing /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy or /etc/PolicyKit/PolicyKit.conf
I think this might be because of policykit doesn't parse SystemToolsBackends for some reason (the syntax seems OK though):
polkit-config-file-validate /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy
[WARN 3378] skipping unknown tag <policyconfig> at line 5 of /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy
... and so on for every line in the file

This is happening on Ubuntu 10.04.1 LTS, system-tools-backends 2.9.4-0ubuntu1

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Razvan: polkit-config-file-validate is for PolicyKit0, while Lucid is (mosty) using the incompatible PolicyKit1. So ti's expected that config files cannot be parsed correctly by this tool. Same for polkit-gnome-authorization, which doesn't work with PolicyKit1, and won't show its actions.

In the future, please avoid hijacking bug reports that are completely unrelated to your problem, thanks!

Revision history for this message
Razvan Cosma (rg-cosma) wrote :

Milan: sorry for the confusion, I did check with an apt-cache show system-tools-backends and man polkit-config-file-validate but nothing in there suggested whether these files are complementing, obsolete or conflicting with policykit-1
As for the problem: it is the same as the one detailed above in the thread, i.e. several GUI admin functions including mounting removable drives and local encrypted partitions do not work when connecting with the NoMachines NX server. Everything is fine from the local Gnome session, or in a terminal.
I have tried the workarounds suggested, and none works.

Revision history for this message
Jeff Ebert (jeffrey-ebertland) wrote :

The workaround for "Karmic or newer" does not work on Maverick server install with ubuntu-desktop added via tasksel. Has anybody had success with it or found a different workaround? Should I file a new bug?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

OK, so according to upstream it's not a bug in PolicyKit, but in the services that specify <allow_active> instead of <allow_any>. Of course, it would be better if ConsoleKit detected remote sessions as active, but there's no reason anyway why the system-tools-backends shouldn't be available to inactive users, so let's do it.

If you find other packages where it's also an issue, we should consider them too.

Changed in policykit-1 (Ubuntu):
status: Confirmed → Invalid
Changed in policykit (Ubuntu):
status: Confirmed → Invalid
Changed in system-tools-backends (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
marstonstudio (jon-marstonstudio) wrote :

Seeing the problem continuing on 10.10, unlock button for gnome useradmin disabled when logging in through freenx

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

I've eventually pushed the <allow_any> fix to the system-tools-backends upstream, it should be available in 2.10.2 for Natty.

Somebody should really go over all actions from /usr/share/polkit-1/actions/ and file a new bug task for all actions that don't consider <allow_any> as a valid case without a good reason.

Changed in system-tools-backends:
status: New → Fix Released
Revision history for this message
jhansonxi (jhansonxi) wrote :

This also affects X2go (package from repo at http://wiki.x2go.org/installing_x2goserver-home_ubuntu)

Revision history for this message
jhansonxi (jhansonxi) wrote :

Instead of directly editing policy files (which may get overwritten on updates), try the attached pkla file (manpage: pklocalauthority). Put this in /etc/polkit-1/localauthority/50-local.d with root ownership.

Changed in policykit:
importance: Critical → Unknown
Changed in policykit:
importance: Unknown → Critical
Revision history for this message
Ben Shadwick (benshadwick) wrote :

I'm seeing this issue with both Maverick and now Natty with x2goserver-one.

jhansonxi's fix doesn't work for me.

I'm using system-tools-backends 2.10.1-2ubuntu1, so maybe Milan's fix will flow down soon?

What's the best workaround at this point?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Ben: Edit /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy, and replace all <allow_active> with <allow_any>. The fix isn't likely to enter Natty at this point.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

Milan: Thanks. That seems to have at least partially fixed things, as update-manager and users-admin are now properly prompting for password and allowing access to locked items.

Unfortunately the Unlock button of gdmsetup still doesn't work, but maybe something else is going on there? If I run it from console I get no message when clicking Unlock.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Ben: Of course, you'll need to make the change for every action that doesn't work. gdmsetup uses a different PolicyKit action. Have a look at files in /usr/share/polkit-1/actions/ and try to guess what are the files you need to edit. Then it's probably useful to file bugs so that it's fixed upstream, if applicable.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

Thanks again. I was able to fix gdmsetup by making the suggested changes to gdm.policy.

I'd happily submit a bug report if I knew where and what to report.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

Update: Submitted a report to the GNOME bug tracker ( https://bugzilla.gnome.org/show_bug.cgi?id=649042 ) and linked this bug to both that report and the gdm project entry here on launchpad.

Changed in gdm:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
David B (divergent) wrote :

On 11.04, I was able to get around this problem by setting my NX client to launch gnome-session --session=classic-gnome .

Revision history for this message
Derek Simkowiak (ubuntu-cool-st) wrote :

Milan said in #62: Have a look at files in /usr/share/polkit-1/actions/ and try to guess what are the files you need to edit. Then it's probably useful to file bugs so that it's fixed upstream, if applicable.

What are the criteria to know what files need to be edited? I saw org.freedesktop.SystemToolsBackends.policy and gdm.policy mentioned above. Are those the only two?

Would it be more correct to replace every "allow_active" with "allow_any" in 100% of those files? There are 25 files that say "allow_active" in them.

I want to help fix this bug, which means filing a bug report for every package that needs a revised policy file, like gdm and system-tools-backends:

root@cst8:/usr/share/polkit-1/actions# dpkg -S gdm.policy
gdm: /usr/share/polkit-1/actions/gdm.policy
root@cst8:/usr/share/polkit-1/actions# dpkg -S org.freedesktop.SystemToolsBackends.policy
system-tools-backends: /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy
root@cst8:/usr/share/polkit-1/actions#

I just don't understand what criteria to use to know which other packages should have a bug filed.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

I'm unsure as well, and given the fact that my gdm bug report is still listed as "UNCONFIRMED" after 4+ months, so I'm not too motivated/encouraged at this point to perform the legwork necessary to report this issue everywhere.

It also doesn't do a single thing to prevent future developers from making the same mistake.

Like Derek, I also wonder if "allow_active" is *ever* appropriate to be used in favor of "allow_any" (at least by default). I did a search-and-replace on all files in that directory at one point, but I'm pretty sure that my changes have been slowly regressing as updated versions of the affected components are installed on my system.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Derek:
The criteria is that you hit this bug on a certain package. ;-)
I think most packages should be fixed, even if a small minority should keep using allow_active: it can only be useful when e.g. managing hardware, sound, mounted devices, etc. In these cases, only the current user should be allowed to run the action. But in most cases, it's too much of a restriction, and if you feel the need for the change, it's probably that it should happen.

One way to find these packages is to run
grep -R "<allow_any>no" /usr/share/polkit-1/actions/
and then check each file and try to guess whether the use of allow_active only is legetimate or not. Then, file a bug uptsream and open a bug watch here.

Ben:
One reason why GDM devs haven't replied can be that upstream's 3.0 uses GSettings for gdmsetup, and doesn't suffer from the bug. Ubuntu would need to check that. Other maintainers might be more responsive.
If you fear that people will make the same mistake in the future, then you can write a simple patch the the Polkit tutorial. Notably, the example config file could have <allow_any>auth_admin</allow_any> instead of "no", or a comment could explain what reasonable defaults are. You can find them at:
http://cgit.freedesktop.org/PolicyKit/tree/docs

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ltsp (Ubuntu):
status: New → Confirmed
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Is this still an issue in recent Ubuntu/LTSP versions?

Changed in ltsp (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Since noone has answered for 4 months, and since some related commits have been made, I'm marking it fix released in LTSP.

Changed in ltsp (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
benok (benok1) wrote :

I've just installed 16.04LTS and confirmed this problem still exists.

And there's no org.freedesktop.SystemToolsBackends.policy in /usr/share/polkit-1/actions.
I tried to find related policy, but I couldn't.

Is there any workaround to fix this with polkit settings like https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/221363/comments/58 ?

Thanks in advance.

Changed in gdm:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.