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

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.

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

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?

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

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

I am having this problem too.

Please let me know if a fix is available.

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.

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.

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

@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?

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

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

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

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.

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.

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

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.

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

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

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.

The packages are:
http://launchpadlibrarian.net/15610243/freenx-session-launcher_0.7.2-0ubuntu0ppa16_amd64.deb
and
http://launchpadlibrarian.net/15608046/freenx-session-launcher_0.7.2-0ubuntu0ppa16_i386.deb

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!

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

But i will try it...:)

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.

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.

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

closing Ubuntu task

Hi,

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

Thanks,

James

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.

Closing the FreeNX task, it is fixed in FreeNX 0.7.3

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.

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

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!

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.

Nice fix Marcelo, worked great for me!

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.

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

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.

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

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

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

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

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!

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.

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?

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.

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

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.

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

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.

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?

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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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

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.