no policykit access on ltsp thin client

[David Burgess]

Not sure if this should be pinned to policykit or the ltsp project.

The unlock button does not work in control panels such as "users settings" on thin clients. Is it possible to implement this? Is this a bug or a feature? Some of my staff are administrators and should be able to add users but they do not have access to the server room. In the days before policykit, Ubuntu administrators were able to add users without having to know CLI.

db

[Michael Cook (michaelcook-mjc)]

I've seen this problem when I install Xvnc (vnc4server) and attach to the host. Local display (via terminal screen) allows me to unlock users & groups, or 'system services'. When I vnc I cannot unlock as the button is greyed out. This is a pain and doesn't exist in Ubuntu, only my first installation of Xubuntu 8.04. Again, like original description my system is not accessible via a local terminal.

Another minor gripe which may or may not be related is the screensaver never kicks in Xubuntu compared to Ubuntu where it kicks in after a timeout and locks the screen. I dont know if this is related to this 'admin' thin-client issue or there is another bug raised?

[TylerF (gtone23)]

This also occurs when using NoMachine (another VNC-like remote desktop app). This bugs make administering headless boxes very difficult. I'm using Ubuntu 8.04 LTS desktop. Just installed latest patches and rebooted.

[Michael Blinn (mblinn-gmail)]

*Bump* -- Same here. I've tried, from the console, clicking 'Allow remote system administrator login' in gdmsetup->Security tab but this makes no difference.

With FC6 I exclusively used a separate computer to administer the server, via NX as well as logging in from a thin terminal. Both of these options are now unavailable in Ubuntu 8.04.

[Alessandro Rinaldi (rinaldi-aless)]

Same thing here!
And it's really annoying to login to the server each time I need to do something! :-)

[Barleyman (john-eberly)]

same here, fresh 8.04 install through NX server. Headless machine, so editing directly on server not an option.

[paulsdavies (paul-s-davies)]

I am having this problem too, but it also manifests itself in other ways when connected via thin client (NX) such as being unable to mount my iPod to use in Amarok - which works perfectly if connected locally to the computer.

[James Westby (james-w)]

Hi,

I believe that there may be a few separate issues going on here,
though they may have the same root cause. Namely, we have people
using

  1. ltsp
  2. Vnc
  3. NX

where ltsp apparently uses ssh.

Fixing this may require fixes in three places and if so I would like to
split this bug report in two three parts. This bug will remain for the
ltsp problem. I have just filed two more bugs:

  Vnc: bug 238799
  NX: bug 219473

Please proceed to the bug which concerns you and subscribe there.
Please also provide the extra information I have requested there.

For the ltsp bug report (this one), I would like the output of

  ck-list-sessions

and

  polkit-auth --show-obtainable

Thanks,

James

[James Westby (james-w)]

Hi,

Sorry, there was a copy and paste error in my last comment,
the NX bug is bug 238800.

Thanks,

James

[David Burgess (apt-get)]

# ck-list-sessions
Session4:
 uid = '1000'
 realname = 'David ****,,,'
 seat = 'Seat4'
 session-type = ''
 active = TRUE
 x11-display = 'localhost:12.0'
 x11-display-device = ''
 display-device = '/dev/pts/1'
 remote-host-name = '192.168.0.248'
 is-local = FALSE
 on-since = '2008-06-12T02:18:45Z'
Session5:
 uid = '1000'
 realname = 'David *****,,,'
 seat = 'Seat5'
 session-type = 'ck-launch-sessi'
 active = FALSE
 x11-display = '192.168.0.248:6'
 x11-display-device = ''
 display-device = ''
 remote-host-name = ''
 is-local = FALSE
 on-since = '2008-06-12T02:18:45Z'
Session6:
 uid = '1025'
 realname = 'Tristen ****,,,'
 seat = 'Seat6'
 session-type = ''
 active = TRUE
 x11-display = 'localhost:10.0'
 x11-display-device = ''
 display-device = '/dev/pts/0'
 remote-host-name = '192.168.0.247'
 is-local = FALSE
 on-since = '2008-06-12T02:20:57Z'
Session7:
 uid = '1025'
 realname = 'Tristen ****,,,'
 seat = 'Seat7'
 session-type = 'ck-launch-sessi'
 active = FALSE
 x11-display = '192.168.0.247:6'
 x11-display-device = ''
 display-device = ''
 remote-host-name = ''
 is-local = FALSE
 on-since = '2008-06-12T02:20:57Z'

# polkit-auth --show-obtainable
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:206:kit_hash_insert(): key != NULL
 Not built with -rdynamic so unable to print a backtrace
[WARN 10741] kit-hash.c:294:kit_hash_lookup(): key != NULL
 Not bui...

[James Westby (james-w)]

Hi David,

Thanks for the extra information. Do you know which of the sessions
listed in the ck-list-sessions output is the one that you ran the second
command on?

I expect the problem has something to do with the output of the second
command though. I don't know from where the error comes, but it
looks legitimate, and may well be the root cause of the problem. I will
look in to the code for any clues.

Thanks,

James

[David Burgess (apt-get)]

There were users logged in on 2 thin clients at that time and nobody on the
server. For some reason the first command listed 2 sessions per logged-in
user. Both commands were run by uid 1000, so session 4 or 5.

I should also mention that the network in question uses the
"LDM_DIRECTX=True" option in lts.conf, making for an unencrypted ssh
connection between client and server. I'm not sure if this is relevant or
not.

(
http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/customizing-thin-client.html
)

db

[James Westby (james-w)]

Hi,

I've found a possible reason for this behaviour, so I have filed an
upstream bug, and I will wait for the author's reaction.

It's possible that this isn't the cause of the bug for you, but it
is a good place to start.

Thanks,

James

[Holden Hao (holdenhao)]

I just wanted to add that this affects remote X-logins as well. When I am logged in through GDM from a different computer the unlock button in the users administration GUI is also grayed out.

Here are some data:

Ubuntu Hardy Heron
--installed from server 64
--apt installed ubuntu-desktop

root@donald:~#ck-list-sessions
-----cut------
Session10:
 uid = '1000'
 realname = 'Holden Hao,,,'
 seat = 'Seat8'
 session-type = ''
 active = FALSE
 x11-display = '192.168.1.111:1'
 x11-display-device = ''
 display-device = ''
 remote-host-name = '192.168.1.111'
 is-local = FALSE
 on-since = '2008-07-05T04:06:38Z'
------cut end-----

Other note:
Access to local devices on the server such as a scanner exhibit similar behavior. Users can use the scanner if directly logged in to the server. However, from their remote x-sessions, Xsane can not detect the scanner. This is true even if implicit policy kit access to the scanner is already anyone "yes", console "yes", and active console "yes". I will post the same info in another bug report.

Holden

[James Westby (james-w)]

Hi Holden,

Please file a new bug as you appear to have a different
problem. You have a valid consolekit session, it's just
marked as inactive and remote, so the policy won't accept
it. We need to work out why that is.

Thanks,

James

[Patrick Rady (prady)]

This problem affects us as well, we are using Ubuntu 8.04.1 64 bit, with LTSP 5, and can no longer perform administrative tasks via the GUI. I can use the command line, but this change makes life very inconvenient, especially since our servers are headless...

[gord-s (gord-sssnaps)]

this worked-around/solved it for me:

I log in as "myself" over an ssh -X session, then do "sudo polkit-gnome-authorization". On the screen that opens (via the forwarded X session), I then allow "myself" to admin things _remotely_, rather than at a physical session at the server.
The setting to change is under the branch
org > freedesktop > systemtoolsbackends ~ "MANAGE SYSTEM CONFIGURATION"

click GRANT, add yourself from the dropdown list, and __crucially__ select the "Must Be In Active Session" button. (rather than locally, for example)

It will show up in the list as "granted by root", as you ran the tool with Sudo

Full explanation and _all_ credit goes to the original poster "pvdploeg" here:

http://ubuntuforums.org/showpost.php?p=5338789&postcount=24

( to save your headaches he uses an random example username of "PPP" )

This works on all my headless/LTSP boxes; but good luck with yours

Note: the greyed out box changes subtly, it remains greyed out, but its icon is now in colour; there is no need to click the troublesome box anymore!

Test and report please, there are many similar/duplicate bugs to this, we need a concerted effort to pin it down.

Maybe we were all barking up the wrong tree? After all, all these "greyed out when remote" problems are gnome admin applets or similar?

I'm still puzzled by this, but at least I can work properly now.
Fingers crossed+comments/tests please.
I'll leave it to someone with a less mangled policykit install to follow further, I nearly broke all of mine trying to get this bug sorted out :)

Needs a thorough security gaze too, this is simply a workaround in my eyes, though it may (hopefully) lead us to a real answer.

[Alessandro Rinaldi (rinaldi-aless)]

This workaround doesn't work for me on both LTSP and ssh -x accesses...

[tonyw (tony-whyman)]

Perhaps worth noting is that I have seen the same problem for locally connected terminals with MultiseatX on 8.04. Seems that policykit only works for a local console on a single terminal system.

[Karl Rosenbaum (kalle)]

The "Must Be In Active Session" option didn't work for me, but if I chose "None" instead it works as described by gord-s.

[Sotir Rangelov (rangelov)]

Holden Hao,

**
Other note:
Access to local devices on the server such as a scanner exhibit similar behavior. Users can use the scanner if directly logged in to the server. However, from their remote x-sessions, Xsane can not detect the scanner. This is true even if implicit policy kit access to the scanner is already anyone "yes", console "yes", and active console "yes". I will post the same info in another bug report.
**

Did you post this info in another bug? I tried to find it but in vane.

The issue with the scanner is very important for me and the lack of solution forces me to stay on Ubuntu 7.10, now that even 9.04 is on its way. I created another bug about this. So far no solution.

https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/323933

If any one have any idea how to solve this, I will highly appreciate it.

Sotir

[Holden Hao (holdenhao)]

> Did you post this info in another bug? I tried to find it but in vane.
>
> The issue with the scanner is very important for me and the lack of
> solution forces me to stay on Ubuntu 7.10, now that even 9.04 is on its
> way. I created another bug about this. So far no solution.

I cheated. I simply created a udev rule. My
/etc/udev/rules.d/42-local.rules contain the following:

------------------------------------
SUBSYSTEM=="usb", ATTR{idVendor}=="04a9", ATTR{idProduct}=="220d",
SYMLINK+="scanner_lide20", MODE="0777"
------------------------------------

I simply used a 777 permission for the device. This is not secure.
It is just a quick hack. For more info on creating udev rules visit

http://www.reactivated.net/writing_udev_rules.html

Regards,

Holden

[Sotir Rangelov (rangelov)]

Holden,

Thank you!

I created the following rule and now it is working as expected:

-------------
SUBSYSTEM=="usb", ATTR{idVendor}=="04a9", ATTR{idProduct}=="2220", SYMLINK+="%k", GROUP="scanner"
-------------

As you can see, instead of giving a 777 permissions, I changed scanner's group, thus only users allowed to scan can access the scanner.

Sotir

[sm8ps (sm8ps)]

Contrariwise to what Alessandro Rinaldi wrote on 2008-10-20, the work-around proposed by gord-s on 2008-09-18 does work for me via LTSP5 on ubuntu 8.04.
Indeed, logged in via LTSP, I perform the ssh -X again into the LTSP server and grant rights to "myself". After that, it all works well as described by gord-s.
Cheers and thank you all for the collaborative work!
St. Mueller, Switzerland

[sm8ps (sm8ps)]

This is a follow-up to my above post.

Only after reading Karl Rosenbaum's post from 2008-12-06, I recalled that indeed I had replaced the "Must Be In Active Session" option by "None" as well. With that option, it works well as described in my previous post.
St. Mueller

[Roland Giesler (lifeboy)]

Additionally to setting the "Must Be In Active Session" option to "None", I also had to set the Implicit Authentication" for anyone to "Admin Authentication" before this would work.

I'm using Jaunty 64bit Server with LTSP. Now I can access "users-admin" via and "ssh -X" session and also from a thin client session.

But these problem should be addressed. They've been in Ubuntu 64 Server since Hardy, which is two releases ago.

regards

Roland

[AM (macchi)]

It is our opinion that the importance assigned for this bug should be higher.
This problem prevents efficient remote administration of systems and servers though a graphical interface and indicates risks for weaknesses in the authorization mechanisms in Ubuntu.
This is pretty serious since we are not able to recommend Ubuntu for production environments, even though we would love to deploy Ubuntu desktops for our business users.

[Jordan Erickson (lns)]

I had this issue as well while trying to use "System -> Administration -> Services" with a user/member of the 'admin' group, using VNC and LTSP clients.

Please see comment #14 at http://ubuntuforums.org/showthread.php?p=8001955#post8001955 for my workaround.

This seems to be a default Ubuntu polkit policy issue (for many things, it seems Ubuntu wants you to be on the actual system console and not logged in remotely via any means)... I don't understand this as it would be trivial to trick PolKit into thinking you're logged in locally even if you're not.