Locking down a user and/or do not launch additional copies of one app

Thu Jul 19 11:32:10 BST 2012

Chuck Burns posted on Thu, 19 Jul 2012 00:27:07 -0500 as excerpted:

> My little girl has her own login (she's 5) and she manages to unlock the
> widgets, remove taskbar from the panel, and then launches her games.
> Over and over.. since she doesn't see them running any more.
> 
> Is there any way of:
> 
> a) Making it where she can't unlock the widgets without a password
> 
> and
> 
> b) Prevent launching any of the kdegames more than once? If you try to
> launch another, the one that is already running is brought back into
> view, ala Restore Window ?
> 
> I'm not above scripting this behavior if it's even possible.  Thanks

Given that you mentioned scripting, it's certainly possible, at least the 
multiple running instances bit (b).

I don't know about (a), tho it is of course possible to set the various 
config files read-only, so at least the changed config can't be saved and 
a new login brings back the saved config.

With reasonably new versions of kde4 (I'm not sure when it was 
introduced, but kde 4.5 or so seems about right, maybe the possibility 
was their before that, but without anything implementing it), it's also 
possible to javascript plasma, and in fact, if your version of kde/plasma 
has (with widgets unlocked) the option to add panel, default panel, what 
that function actually does is invoke a javascript that adds an empty 
panel and adds the default set of widgets, etc, to it.  I remember 
reading about this on the blogs when they were first implementing it.  
However, you'd probably have to ask on the plasma list for more details 
or just investigate that script and create your own, but see below for 
additional resources to check first.

Back to (b).

There is a command-line application called wmctrl (window-manager 
control), that is likely in your distro's package tree (I installed and 
use it in my own scripts here on gentoo, for instance).  This app lets 
you bash/shell-script various window actions, generally matched on window 
title.  You can resize and place windows, minimize, maximize, close, move 
them to different virtual desktops, add or delete virtual desktops, 
switch the current virtual desktop, etc.

wmctrl homepage:  http://tomas.styblo.name/wmctrl/

FWIW, there's another app, wmiface, with similar but more advanced 
functionality, actually developed by a kde dev, Lubos Lunak, and hosted 
at kde-apps.org.  However, while it does have more advanced 
functionality, it's more suited to those who think in C/C++ type code 
even when they're shell scripting, as you'll see if you try reading its 
documentation (manpage, etc).  I tried it, but decided wmctrl did what I 
needed and was easier for me to use, so uninstalled this app and kept 
wmctrl.  FWIW wmiface is also available in gentoo, but I'd guess it's 
less commonly available in distros than wmctrl.

wmiface homepage:

http://kde-apps.org/content/show.php/WMIface?content=40425

What you'd do here, would be to create a wrapper script that when 
launched, uses wmctrl (or wmiface) to try to match an existing window for 
that app and bring it forward and into focus.  If no existing window 
matches, it would launch a new instance of the app.  With wmctrl and even 
a bit of basic shell-scripting knowledge, this should be reasonably 
simple.  Of course, don't forget to set the executable bit on your 
scripts, but if you know anything about scripting, that's already a given.

Next, you edit the menu entries for the desired apps (kmenuedit does 
this, run it from krunner or kickoff, or from the context menu of the 
various launch menu widgets, kickoff, classic kmenu, etc), pointing them 
at the wrapper script instead of the original kde app, so when they're 
launched, the script raises and activates the app's main window if it 
exists (switching to a different virtual desktop if necessary to do so, 
or bringing the app onto the current virtual desktop if desired 
instead... tho you can ignore this bit if your daughter hasn't discovered 
virtual desktops yet), and launches a new instance of the app, if not.

Alternatively and perhaps easier for someone who you might prefer to have 
a more limited launcher, you can delete kickoff/classic-menu/lancelot 
plasmoids and replace them with one of several icon-based app-launchers, 
changing it to point to the wrapper script instead of editing the menu.

Yet another (system level, root privs required) alternative would involve 
moving the actual binaries from their normal location in, probably, /usr/
bin, to a different directory not on the normal path (say /usr/wrapped-
bin), replacing them with the wrapper-scripts, which could then launch 
them via absolute path (/usr/wrapped-bin/kpat, for example).

FWIW, this type of wrapper script is a reasonably common solution to this 
sort of problem, and one I use regularly here, tho generally to solve 
different problems.  For instance, I have two separate instances of claws-
mail, one for handling my mail (after kmail akonadified and got hugely 
buggy, so I had to dump it), one (with the feed plugin) as my feed 
reader.  Most folks would just use the one instance for both, but I 
wanted my feeds handled separately.  So I have wrapper scripts for both 
instances, one that sets up a few environmental vars to point claws at 
the mail dir, one that sets them up differently to point it at the feeds 
dir and keep the two from interfering with each other.  Similarly, I use 
pan for news (nntp), but have three different instances and wrapper 
scripts for it, one for text groups (mostly mailing lists followed as 
newsgroups, including this one, via gmane's list2news service), one for 
binaries, and one for testing, as I'm a regular on the pan lists and 
sometimes need to check posts that are giving people trouble, without 
screwing up my normal pan config.  Wrapper scripts are thus a quite 
common generally routine solution to such issues.

Additional resources:

http://techbase.kde.org

... has a number of additional resources you may find useful.  In 
particular, there's a whole mini-site's worth of pages on kde system 
administration that's WELL worth reading.

http://techbase.kde.org/KDE_System_Administration

The sections on the file system, kde and xdg hierarchy, and environmental 
variables have been QUITE some help here, in understanding and 
customizing my configuration.

But the kiosk information should be more direct to what you're trying to 
do here, since the idea is to lock down settings in a public kiosk 
environment, and that's basically what you're interested in doing for 
your daughter, as well.  I won't link that specifically here as there are 
several kiosk related links under user and group profiles, plus the kiosk 
tool under tools, at the above sysadmin link.  So several pages/links for 
that, at the above.

Additionally, there's more information on the plasma desktop javascripting 
I mentioned above.  That's covered here:

http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting

Someday I need to read thru that and see what I can make use of from 
it...  I'm more a shell-scripter than a javascripter, but with the 
examples and such, I could probably do something with it, at least...

Meanwhile, the plasma techbase section moved to the community.kde.org 
wiki, and can be found here:

http://community.kde.org/Plasma

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.