Policy Kit Unlock Buttons Greyed Out when using NX
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| FreeNX Server |
Medium
|
Unassigned | |||
| PolicyKit |
Unknown
|
||||
| policykit (Ubuntu) |
Undecided
|
Unassigned |
|
||
| Nominated for Hardy by gozotto | |||||
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
== Workaround ==
From https:/
For system configuration, change all implicit authorizations under org -> freedesktop -> systemtoolsbackends -> Manage System Configuration (org.freedeskto
For user management, change all implicit authorizations under org -> freedesktop -> systemtoolsbackends -> self -> Change User Configuration (org.freedeskto
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.
| Craig Younkins wrote on 2008-04-26: | #3 |
Why is this a "n00b error"?
There are a whole people here ( http://
| description: | updated |
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://
Please let me note that I'm interested in a solution for this problem, too.
| paulsdavies wrote on 2008-06-09: | #6 |
I am having this problem too.
| houstonbofh wrote on 2008-06-25: | #8 |
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.
| Marcelo Boveto Shima wrote on 2008-06-25: | #9 |
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-
- Execute $ chown nx /usr/bin/
- Execute $ chmod 4755 /usr/bin/
- Copy ConsoleKit-NX.conf to /etc/dbus-
- Edit /etc/nxserver/
to 'COMMAND_
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.
| Marcelo Boveto Shima wrote on 2008-06-25: | #10 |
| Marcelo Boveto Shima wrote on 2008-06-25: | #11 |
| Marcelo Boveto Shima wrote on 2008-06-25: | #12 |
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/
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.
| Marcelo Boveto Shima wrote on 2008-06-25: | #15 |
Do you use any package or is built from scrap?
Try to change this line on the file /usr/bin/
| Marcelo Boveto Shima wrote on 2008-06-25: | #16 |
Try to chance the session configuration on nxclient to unix-custom instead of unix-gnome.
In application put /usr/bin/
Or maybe there is a configuration file on /usr/NX/etc
Tried with both:
edit /usr/NX/
changed my client profile to custom and added /usr/bin/
| houstonbofh wrote on 2008-06-25: Re: [Bug 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX | #18 |
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.
| Marcelo Boveto Shima wrote on 2008-06-25: | #20 |
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:/
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
f493e0b30e55410
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-
So if you don't set a active=TRUE and is-local=TRUE session on ConsoleKit
PolicyKit won't work.
| Marcelo Boveto Shima wrote on 2008-06-25: | #21 |
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-
convidado@laptop:~$ nx-session-
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-
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-
convidado@laptop:~$ nx-session-
How it works?
- $ ck-list-sessions
shows my X session
- $ nx-session-
- $ nx-session-
The PolicyKit button is not grayed
| Marcelo Boveto Shima wrote on 2008-06-25: | #22 |
I forgot to tell that ck-session launcher is compiled for i386.
| Marcelo Boveto Shima wrote on 2008-06-25: | #23 |
I've created a package to be used with NX Free edition.
But you have to edit /usr/NX/
- CommandStartGno
to
- CommandStartGno
The package is in the building queue, once it finish I will post the DemoUrl here.
| Marcelo Boveto Shima wrote on 2008-06-26: | #24 |
After installing the above package and making the change to /usr/NX/
Nicely done Marcelo!
| Zdeněk Dlauhý wrote on 2008-06-27: | #26 |
I think that must be repaired in the PolicyKit, not in the NX/FreeNX/SSH....
| Zdeněk Dlauhý wrote on 2008-06-27: | #27 |
But i will try it...:)
| Marcelo Boveto Shima wrote on 2008-06-27: | #28 |
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.
| Changed in freenx: | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
| Marcelo Boveto Shima wrote on 2008-07-26: | #30 |
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/
'#COMMAND_
to 'COMMAND_
gnome-session'
Thanks
| Changed in policykit: | |
| status: | Unknown → Confirmed |
| Jean-Baptiste Lallement wrote on 2008-08-01: | #31 |
closing Ubuntu task
| description: | updated |
| James Westby wrote on 2008-08-05: | #32 |
Hi,
Please don't close the Ubuntu task, this is still a problem with
Ubuntu.
Thanks,
James
| description: | updated |
| description: | updated |
| houstonbofh wrote on 2008-08-09: | #33 |
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.
| Marcelo Boveto Shima wrote on 2008-09-03: | #34 |
Closing the FreeNX task, it is fixed in FreeNX 0.7.3
| NTolerance wrote on 2008-11-03: | #35 |
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.
| Marcelo Boveto Shima wrote on 2008-11-04: | #36 |
I supposing you are using NoMachine NX Free edition.
So add the repository:
deb http://
And use the freenx-
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-
Cheers!
I'm using the NX Free Edition Server on Intrepid, and when I try to install the latest freenx-
| Cyber Source wrote on 2009-02-03: | #39 |
Nice fix Marcelo, worked great for me!
https:/
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 |
| Changed in policykit: | |
| status: | Confirmed → Invalid |
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.