policykit not available over Vnc sessions

Bug #238799 reported by James Westby
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
policykit (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: policykit

Policykit does not work over Vnc sessions. The unlock button in the
admin utilities is greyed out.

This bug was split out from bug 219473.

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

Hi,

Could someone who is experiencing this bug please provide the output
of

  ck-list-sessions

and

  polkit-auth --show-obtainable

when logged in over a Vnc session?

Thanks,

James

Changed in policykit:
status: New → Incomplete
Revision history for this message
Dave Radin (spam-davidradin) wrote :

I experience this bug too.

Here is the output requested. The second command doesn't give any output for me over VNC or SSH.

david@meadows-server:~$ ck-list-sessions
Session2:
        uid = '1002'
        realname = 'Meadows user account'
        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-23T19:03:02Z'
        idle-since-hint = '2008-06-23T19:16:21Z'
Session1:
        uid = '1000'
        realname = 'David Radin'
        seat = 'Seat2'
        session-type = ''
        active = TRUE
        x11-display = ''
        x11-display-device = ''
        display-device = '/dev/pts/0'
        remote-host-name = 'adsl-69-209-239-109.dsl.chcgil.ameritech.net'
        is-local = FALSE
        on-since = '2008-06-23T18:48:08Z'
Session3:
        uid = '1000'
        realname = 'David Radin'
        seat = 'Seat3'
        session-type = ''
        active = FALSE
        x11-display = '127.0.0.1:50'
        x11-display-device = ''
        display-device = ''
        remote-host-name = '127.0.0.1'
        is-local = FALSE
        on-since = '2008-06-23T19:12:42Z'

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? This works as expected for me in Intrepid. Can you try with latest Ubuntu release?

The unlock button may be greyed out depending on the system policy (ie, no privileges are available from the current console).

Thanks in advance.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

I still see this issue with XUbuntu and Ubuntu 8.04 with the latest patches. I've not had to manage the users & groups and with the updated VNC packages from http://www.francescosantini.com/index.php?page=linux&lang=en the latency and X Window issues have been resolved. I've tried to follow the thread on this vnc issue but couldn't. Installing the packages from the above website addressed the latency but not the 'unlock' features on some Admin consoles such as users & groups.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

Forgot to mention: trying Intrepid is not an option at this time.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I just tried Hardy, and this behaves as expected for me.

The Unlock button should always be greyed out in users-admin by default when running over a SSH session, as the default Ubuntu policy for this action is to only grant authorization when running on the active console. A SSH session can never be on the active console.

The Unlock button in users-admin is active for me over VNC when the users session on the local machine is on the active console. If the users session is on an inactive console, PolicyKit will not grant any authorization, as this is the default Ubuntu policy (which you can adjust BTW).

The empty output of "polkit-auth --show-obtainable" is what I would expect to see if the session that is called from is not on the active console, unless you have altered the Policykit settings on your machine.

For those of you experiencing a problem, please provide the output of the following commands (obtained from within your VNC session only):

"ck-list-sessions"
"polkit-auth --show-obtainable"
"dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetCurrentSession"

Thanks in advance

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

Thanks for your email Chris... you've probably guessed... but myself at least I am a bit of a noob when it comes to policy kits. So I take it on faith that this is all working as *expected* but it is at least a change in behaviour compared to previous configurations I had before (with very little configuration on my part).

I have not modified anything to do with policy kits and not sure how to edit them so VNC client could access 'unlock' button for example on the User & Groups panel. I have vncserver kicking off on bootup instead of remote-desktop which was sluggish until I updated the vncserver package as described above.

Meanwhile, here is the output to the commands you are looking for:

ck-list-sessions
Session1:
 uid = '1000'
 realname = 'Michael,,,'
 seat = 'Seat2'
 session-type = ''
 active = FALSE
 x11-display = '127.0.0.1:2'
 x11-display-device = ''
 display-device = ''
 remote-host-name = '127.0.0.1'
 is-local = FALSE
 on-since = '2008-12-05T19:39:01Z'

polkit-auth --show-obtainable
// Nothing

 dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetCurrentSession
method return sender=:1.6 -> dest=:1.32 reply_serial=2
   object path "/org/freedesktop/ConsoleKit/Session1"

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Thanks. That's interesting actually. Consolekit only lists a single session on this seat (Seat2?), which is not the active one and is not local either. This is why you can't authenticate with PolicyKit.

So, there is no bug in PolicyKit here, as it is behaving exactly as expected.

I have to admit, I'm slightly confused why your session is on Seat2. AFAIK, Seat1 is the local seat for most of us desktop users, and I thought that any VNC session would be on Seat1, seeing as it's basically just transmitting the contents of the local seat across the network.

It would be great if you could describe exactly the steps you take on both the client and server-side to make the VNC connection, so I can try and recreate it here and see if there really is a bug.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

My most recent notes about setting this up (some time back) point me to:
- http://www.movingtofreedom.org/2007/02/16/howto-remote-desktop-with-vnc-in-ubuntu-edgy-gnu-linux/
- Adjust gdm.conf (different for Ubuntu vs XUbuntu) and uncomment RemoteGreeter.
- Make sure Remote Login is enabled under Admin settings for Login Window

I dont have a local terminal or local login. I access this box over the LAN from WinXP box using ultravnc.

I suspect the "remote desktop feature" simply relays Seat1 but I've not had much luck setting this up unless I'm already logged in... which is fairly difficult to do since there is no keyboard or screen attached.

The vnc setup above seems to create unique login sessions via VNC instead of simply echoing the local screen/user session. I can log in via VNC under any user I create as I seem to be presented with the 'local greeter screen' via VNC session.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

That makes sense. So, if this is the same setup that everybody else is using, then there is no bug. Policykit won't grant authorizations for you in your VNC session because your session is not on the local console.

This can be adjusted by going to System -> Administration -> Authorizations, but I don't recommend you mess with that too much

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Thanks mc2008 - I just set up a VNC server with the instructions you provided, and I can verify the behaviour you see. As suspected, this is just because you aren't on a local console, and PolicyKit is behaving as expected with the default policy shipped with Ubuntu.

So, I'm going to close this bug as invalid. Thanks for helping out.

Changed in policykit:
status: Incomplete → Invalid
Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

The comical irony of this suggestion to use "Authorizations" panel is that I am not allowed to change anything from my VNC session remotely! ;o) I feel most 'invalid' now.

Revision history for this message
Andrew (hachuah) wrote :

Agree with mc2008. Ubuntu needs to re-look at the policy for those of us (and I'm sure there are many!) who are running headless boxes. How are we supposed to add users/groups?

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

After some consideration I like the 'feature' of authorisations based on local/remote consoles. I have not changed the defaults as it is more secure and I dont have a monitor nearby.

I think it was more frustrating (for a noob) to not know that this was the problem/root cause for 'unlock' being greyed out. Perhaps a pop-up on the greyed-out 'unlock' button saying "remote console: not authorised" would at least give us a clue! I haven't yet run into a wiki guide yet to adjust authorisations via the cmd-line (which I do have sudo access) to enable these features... which would be a happy compromise as I believe 'everything can be done on the cmd-line'... but not sure how. ;o( Any suggestions Chris?

Revision history for this message
Andrew (hachuah) wrote : Re: [Bug 238799] Re: policykit not available over Vnc sessions

I have worked around my problem by using "adduser" on the cmdline to
add my users.
I agree that there at least should be some docs explaining policykit
and why the unlock
button is greyed out.

On Mon, Dec 29, 2008 at 9:21 AM, mc2008 <email address hidden> wrote:
> After some consideration I like the 'feature' of authorisations based on
> local/remote consoles. I have not changed the defaults as it is more
> secure and I dont have a monitor nearby.
>
> I think it was more frustrating (for a noob) to not know that this was
> the problem/root cause for 'unlock' being greyed out. Perhaps a pop-up
> on the greyed-out 'unlock' button saying "remote console: not
> authorised" would at least give us a clue! I haven't yet run into a
> wiki guide yet to adjust authorisations via the cmd-line (which I do
> have sudo access) to enable these features... which would be a happy
> compromise as I believe 'everything can be done on the cmd-line'... but
> not sure how. ;o( Any suggestions Chris?
>
> --
> policykit not available over Vnc sessions
> https://bugs.launchpad.net/bugs/238799
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
sudopod (constantinexiii) wrote :

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.

Revision history for this message
sudopod (constantinexiii) wrote :

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.

Revision history for this message
robled (robled) wrote :

Just attempted sudopod's fix on an Intrepid system. After restarting gdm and logging in via NX Nomachine the "unlock" button in the "Users Settings" applet is now available. Upon clicking it, I get an error message that says "Could not authenticate - An unexpected error has occurred."

I don't know how to run the "Users Settings" applet from a terminal to get more information.

Revision history for this message
Mark Frazer (mark-mjfrazer) wrote :

sudopod's work-around worked for me.

Why does Ubuntu not have a pop-up indicating how to remotely enable remote administration?

Once a box is shipped to a client, it really sucks to find this out.

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.