Prevent KDE Applications to overwrite elektra files

[FelixResch]

Some KDE applications appear to write default settings directly to their configuration file when the keys they require are not present (e.g. plasmashell, baloo). This is no problem, when the keys are loaded from a write protected location (e.g. /etc/) but results in Elektra parsing errors, when the file is in the user namespace.

A work-around would include the following changes:

• move logic whether or not a file should be loaded to the backend and always return true for the Elektra backend
• use /dev/null as file name on unixoids and NUL on windows systems

This way KDE applications can write their configuration and not corrupt the actual files.

[markus2330]

but results in Elektra parsing errors, when the file is in the user namespace.

Please give a concrete example of such parsing error.

move logic whether or not a file should be loaded to the backend and always return true for the Elektra backend

Yes, the application should not know about "if and which configuration files" are involved when using Elektra. So within kconfig no configuration files should be passed, instead only kdbGet&ksLookup should be used to locate configuration.

This way KDE applications can write their configuration and not corrupt the actual files.

It would be even better if they do not write useless configuration (copies from defaults or /etc). Ideally they would only write out keys that they actually changed. See #12

[FelixResch]

Please give a concrete example of such parsing error.

Overwrite ~/.config/default.ecf with any .ini content to make Elektra throw an kdb::KDBException

terminate called after throwing an instance of 'kdb::KDBException'
  what():  Sorry, module dump issued the error C03100:
Validation Syntactic: Unknown command detected in dumpfile: [Section][en].
Maybe the file is not in dump configuration file format? Try to remount with another plugin (eg. ini, ni, etc.)
Mountpoint: user
Configfile: /home/felix/.config/default.ecf

This is thrown, when the KDB instance is created.

Yes, the application should not know about "if and which configuration files" are involved when using Elektra. So within kconfig no configuration files should be passed, instead only kdbGet&ksLookup should be used to locate configuration.

I will implement those changes.

It would be even better if they do not write useless configuration (copies from defaults or /etc). Ideally they would only write out keys that they actually changed.

I fear this is something the KDE dev team is responsible for...

[markus2330]

Overwrite ~/.config/default.ecf with any .ini content

Of course, but why would this happen?

I fear this is something the KDE dev team is responsible for...

You mean people using KConfig?

[FelixResch]

Of course, but why would this happen?

During Plasma start-up some applications write directly to the configuration files to store their default settings. I checked with auditd and the debug messages added to the INI backend to see if the file was accessed by the INI backend, which it wasn't, therefore I suspect that some applications directly write their default configuration to the file which is specified by the backend.

You mean people using KConfig?

Yes and no, more specifically the people developing KDE.

[markus2330]

During Plasma start-up some applications write directly to the configuration files to store their default settings. I checked with auditd and the debug messages added to the INI backend to see if the file was accessed by the INI backend, which it wasn't, therefore I suspect that some applications directly write their default configuration to the file which is specified by the backend.

While this is a disaster from software architecture point of view (violation of layers) it might not matter so much to us as we planned to use @darddan's kconfig plugin anyway. Then we would understand what they directly inject into the config files.

But how do the applications even find out about the config file ~/.config/default.ecf. This is a file specific to Elektra. Do you return the configuration file name somewhere? We should give them application-specific configuration file names to write to.

Yes and no, more specifically the people developing KDE.

I am more and more confused. We are currently developing KDE (specifically kconfig). So who if not we should change the situation?

Of course we would need to discuss bigger changes with the mailinglist.

[FelixResch]

While this is a disaster from software architecture point of view (violation of layers) it might not matter so much to us as we planned to use @darddan's kconfig plugin anyway. Then we would understand what they directly inject into the config files.

I totally agree.

But how do the applications even find out about the config file ~/.config/default.ecf. This is a file specific to Elektra. Do you return the configuration file name somewhere? We should give them application-specific configuration file names to write to.

KConfig requires the backends to set a file name for their configuration and apparently some applications abuse this information.

I am more and more confused. We are currently developing KDE (specifically kconfig). So who if not we should change the situation?

This seems to be a specific problem with some of the applications of KDE (e.g. baloo, plasmashell). I haven't checked in the sources of these projects yet, but I guess this is a problem they need to fix at their side.

[markus2330]

KConfig requires the backends to set a file name for their configuration and apparently some applications abuse this information.

We should not pass out our private config files. Then the problem should disappear (as long for all KDE specific files kconfig is used).

[FelixResch]

We should not pass out our private config files. Then the problem should disappear (as long for all KDE specific files kconfig is used).

I had to implement these changes for #2. KConfig would not reuse the backend, if the backing file would have changed.

Base was read from system and ours in user, because it was already written. As I was using the internal files, changing namespace would result in different files and therefore KConfig creating a new backend with the wrong absolute path.

I would use an URI instead of the filename, or should I use the legacy filenames? URI would have the structure elektra:/<app_name>/<major_version>/<profile>

[markus2330]

URI sounds fine. But please use the same structure as Elektra's path. So elektra:/sw/kde/<app_name>/#<major_version>/<profile>.

See also doc/tutorials/application-integration.md

[FelixResch]

I have changed the URL now and pushed to the branch that is currently in review in #14

[markus2330]

As discussed, please open a new PR.