Hi..I am looking for where to find a complete and up to date list of restrictions that I can apply to a kubuntu 9.04 KDE4 desktop. I am hoping that such a list exists someplace that I haven't yet manged to find.

These include:
[KDE Action Restrictions]
[KDE Resource Restrictions]
[KDE Control Module Restrictions]
[KDE Custom Restrictions]

Currently I only know the 56 action restrictions that kiosktool places in kdeglobals (when i tick all the boxes) but understand there to be others that the kiosktool gui does not cover.

I also have an out of date list of 87 KDE Module Restrictions that was published in 2006 and assume that list has now evolved.

I have googled hi and low but have yet to find such information published anywhere.

Anyone?

While I do not know any of the names of the restrictions, I do know you can enforce settings by making them immutable ( simply add [$i] after the setting / group name in the config files )

There is list of KDE Action Restrictions at http://techbase.kde.org/KDE_System_Admi ... Kiosk/Keys . This page also has keys for KDE Resource Restrictions.

So now I am looking only for a list of KDE Custom Restrictions and KDE Control Module Restrictions, if such a list exists?

[$i] Immutable. Depends where you put it as to what it applies to. The key, the group or the file.

But what happens if another version of the immutable setting is encountered, does the first one hold, or does the new one over ride the old. ?

I mean, if set a specific key in etc/myprofile/share/config/kdeglobals: say
[KDE Action Restrictions][$i]
action/file_new=false

And also in the /home/thisuser/.kde/share/kdeglobals
[KDE Action Restrictions][$i]
action/file_new=true

Since the contents of /etc/kderc defines the order in which config pages are searched, this means the latter version would apply. Or does it?

The Control Module restrictions appear to be accomplished through X-KDE-AuthorizeAction items in the desktop files of the control modules, and the appropriate action restriction being added as normal.

ianz wrote:But what happens if another version of the immutable setting is encountered, does the first one hold, or does the new one over ride the old. ?

You can check the lookup order with the following command:

% kde4-config --path config

A setting encountered from left to right is taken unless it is marked immutable in any config later in the list.

Cheers,
_

% kde4-config --path config

I put this command into the terminal but it returned "bash: fg: %: no such job"

I am using kubuntu 9.04 btw.

Try removing the % symbol like follows:

Code: Select all

kde4-config --path config

Ok, "kde4-config --path config" shows me the four directories where config resources can be located. Some of these loactions have a kdeglobals file, others dont..

In /usr/share/kubuntu-default-settings/kde4-profile/default/share/config/kdeglobals I placed the following directives.

[KDE Action Restrictions][$i]
action/kwin_rmb=false
run_command=false

In theory this should restrict the kwin rmb and the run command for every user desktop on this PC.

On reloading the desktop these directives have no effect on the Alt-F2 run command or the availability of the run command from the kwin rmb. In other words the directives do not work as described in: http://techbase.kde.org/KDE_System_Admi ... Kiosk/Keys

Could this be consdiered a bug? or is the documentation out of date? or is it just me?

Failing resolution of these issues that I am having I am being forced to abandon the whole concept of a kde kiosk and will have to either change to gnome or, dread the thought, back to windoze.

Why is it that kde is so full of promise yet so fickle.

Perhaps someone with more experience than I can try to duplicate the issue, as I would love for it to simply work as described in the docs.

In the spirit of experimentation I have made a brand new kubuntu 9.04 install, with a single user.

I edited /usr/share/kubuntu-default-settings/kde4-profile/default/share/config/kdeglobals and placed the following directives.

[KDE Action Restrictions][$i]
action/kwin_rmb=false
run_command=false

On reload, same result as before, the restrictions do no apply. This proves to me that there is a bug, or a change in the kde desktop lock down process that is not described in the official kde docs, or something.

Is there someone in the kde development team who would know about this?. It could be me doing something silly, as I do not have a long history with linux or kde.

The Kiosk documentation is probably out of date. These settings will likely apply to KDE 3.

bcooksley wrote:The Kiosk documentation is probably out of date. These settings will likely apply to KDE 3.

So how would someone actually find out how things work if it isn't in the doc's. Is it a matter of referring to the source code?

Yes, the source code in particular would likely be the source code for KRunner.

You would probably find it easier to simply lock down which plugins users can enable in KRunner, through the immutable system. Simply create krunnerrc with the needed settings in the same place as the global kdeglobals file. This would stop them from running commands but still allow easy opening of web addresses, installed apps, etc.