Re: Q: How to "freeze" LTSP sessions - and unfreeze later.
On Thu, 25 Nov 2004, Finn-Arne Johansen wrote:
> I think you may be able to specify which screensaver to use, or just
> use blanking
What I mean is that cheeky kids may unlock it and fire up a game, website
etc. Or in an exam they might start work outside the allotted time.
> > Suppose you create a dummy "screenlock" user. A teacher runs the
> > lockdesktops script. This does the following:
> Ahhm, this script has to be run by root, or through sudo, because the
> su-command really changes to the user running that display
This is surely only needed if you want the screensaver to run as that user?
What I'm suggesting is that you run it on all machines as a dummy user
called "screenlock". This means the students don't know the password
(which is set on each lock) and it is common to all machines across the
My pitiful knowledge of unix/setuid may be showing here but could one not
make the script setuid "screenlock"? AIUI this should make the script run
as that user. That way it should have permissions to set the password and
fire off the remote screensaver (it would need to start the process and
On reflection this scheme likely requires that no screensaver process
already be running which is bit of a weakness though not insurmountable.
To be honest I think this is a little far-fetched but am just kind of
interested in it in theory.
Another most undesirable side-effect of any such effort is that of opening
all the thin clients with xhost. Again I may well be wrong but I think it
would then be possible for anyone with a login to the thin client server to
remotely start processes on any thin clients. This could have all kinds of