KDE 3 era (and carried on by TDE) had a GUI interface for locking down settings for an organization or company or whatever else, but was removed I think in the 4.x era. Can that return? It be a great way to show KDE as a serious alternative to GNOME or at the least, a strong competitor.
1 Like
We definitely need this. The issue is that nobody or not enough people stepped up to do the work yet.
What needs to be done so far to considerably improve the kiosk situation? I’ll give the devil its due, but seeing a kconf like database either through command line or a GUI would be wonderful to have like how GNOME does it. Not a 1:1 duplication, but something similar in idea.
Not sure a GUI would be productive because ITOps seems to favor scripting like Ansible now.
Isn’t that already possible (i.e. locking the settings) using chmod -w for ll the Plasma config files? Basically one user admins the system, other users don’t have rights to change the settings → leveraging basic Linux filesystem permissions.
Are you referring to locking the permissions of the user $HOME config? Because that might be a pain with more than one user. And if I recall, KDE uses $XDG_CONFIG_DIRS to locate the /etc/xdg config files, wouldn’t it be possible to get around that by just reassigning upon login the environmental variable value?
Yes, I was referring to changing config file permissions for files (parts of Plasma) that you don’t want users to change.
Somebody else might answer the XDG question, since I don’t know the details here.
Anyone interested in doing this, please refer to the existing docs for Kiosk, by the way: Kiosk - Simple configuration management for large deployment | Developer
Technically this isn’t difficult at all if you can make a Qt app. You can just make a simple GUI for editing Kiosk keys then use KConfig for the actual change, namely KAuthorized for restricting the necessary files.
The tools for this are basically ready and as handholdy as can get, someone just has to do the work.
A Kiosk GUI is one of our missing key points we need to better support Plasma on enterprise.
Another way people can assist with this is by reporting bugs related to whether the Kiosk keys are actually working, because if I recall correctly a few of those keys stopped working. Though note that some of the keys apply only to KDE apps.
3 Likes
Does this necessarily have to be C++? Can it be done using python or maybe even bash if one is adventurous enough?
The other option is Python, as KDE Frameworks are gaining Python bindings across the board.
1 Like
Does this qualify as an official thing? Can a blog post be made about this if so?
You would also need to change the owner otherwise the user can just add the write permission again.
But even then the user might still have permission to delete the file and have it recreated as themselves and with standard permissions.
Yes, however changing the DE startup environment might only be viable for advanced users.
Indeed, the best would be change both the user and group.
I did a quick test and let root create a file in my home directory.
Could still delete it.
What kind of negative side-effects could happen should someone change their $XDG_CONFIG_DIRS path?
As long as includes the previous paths it should be fine.
Like extending $PATH to include user specific directories.
Yeah, unfortunately “you could delete a file owned by root, if you could write to the file’s parent directory.” So this approach won’t work.
I don’t even know if the official docs are updated for new keys or removed keys for plasma 6 or not. Is there someone specific in charge of keeping the docs maintained?
Now, what if said user decided to set their $HOME dir for what should be the system configs ($XDG_CONFIG_DIRS) in front of the /etc/xdg/. Wouldn’t then it overrule the system wide config files? Or if the system wide ones are found, at all, it will always take precedence?
They have not been, which is why I suggested it. It’s in my to-do but if someone wants to do that before me they can.