Registered Member
|
When a KDE component cannot write it's configuration file I get a kdialog message like this viewtopic.php?t=110368
What I want is this pop-up message to not be displayed, because I setup a locked down user environment where some config files are owned by root, immutable and not writable by the user. This causes lots of pop-ups at user login and makes the login process very long, because each affected component hang for 30 seconds and block the login (for example kickerrc). If I ssh in the box and immediately kill kdialog processes, the login is smooth as expected. At the moment I'm loop running a pkill -f "Please contact your system administrator" but I don't like it this way. Is this possible? |
Registered Member
|
Hi!
I do not know how to suppress this message, but I also do not know why root manages user configurations files. You can provide global configurations in /etc /usr/share,… What do you try to achieve? |
Registered Member
|
like I said, "a locked down user environment" aka prevent user from modifying their own stuff like any panel or menu in kicker for example. it does work by owning their files and denying the user write rights and making them imutable, but then you get a cascade of errors from various components that only like to call syscalls that open their config files in write mode at startup but actually write nothing to them. after that, everything works okay but the startup it's not a pleasant experience if you rely only on global configurations, you only get a template but nothing prevents the user to customize it. |
Registered Member
|
Locked down for what purpose? Do you want to create something like a guest session? Then you could reset the changes after users logout. Suppressing error messages in general can be a big problem as they also could be useful
Filtering only these messages you do not want to display it is probably not possible without editing some code. Easiest would be to patch the messaging system to filter them out, but you have to implement it in every new version. You could also replace the notification plasmoid with a custom one. Next problem is disabling the XDG-stuff as every user is able to set up new Paths, e.g. ~/.myconfig instead of ~/.config so there would be a possibility to bypass this. If there is fuse available, users could mount over existing folders, you can try to bypass with shell variables, install software locally, and so on. That's why I am asking why you think you have to restrict the user folder itself, which should not be necessary. Its the users space to set things up like he wants to. |
Registered Member
|
How are you setting this environment up?
https://develop.kde.org/deploy/kiosk/introduction/ ?
claydoh, proud to be a member of KDE forums since 2008-Oct, and KDE user since 2001
|
Registered Member
|
that looks promising, thanks! would have to read more about it. |
Registered Member
|
This workstation is built with only a few functions: - a browser to access an internal website - a file manager to copy files to/from usb drive - a printer to print some pdfs downloaded from internal website It's remote, over low bandwidth private vpn line (no internet, no access to network settings, no console terminal app available), unsupervised by local IT support. Remote Linux support staff skills are limited. All these imply ideally zero alterations to the UI config it has been shipped with while allowing user files in some folder. The users have no experience of linux desktop although themes make it look close to windows UI elements. It's not up to the user to setup things like he wants to The goal is to protect from accidental clicks / curious user, not from malicious user |
Registered Member
|
Didn't know this still exitsts! I thought this was abandoned after Plasma4. Thank you! |
Registered users: Bing [Bot], Google [Bot], Sogou [Bot]