See bug 28882. And along those lines, a small set of sysprefs could somehow be set apart for changes only by superlibrarian. Perhaps even configurable by sysadmin. Example: If you give a staff user Administration privileges, but not superlibrarian, he can now change your MarcFlavour, KohaAdminEmailAddress, OPACBaseURL, etc. It might be possible that you dont want any changes there? ;) Note that sometimes changes could be made even unwillfully but by accident.
This has been discussed already on a separate bug report (or I discussed it privately with somebody else, cannot remember). The idea we had was to have a new section in koha-conf to list sysprefs we couldn't edit from the UI. So it's a bit stronger than what you suggest as only the sysop could modify them.
(In reply to Jonathan Druart from comment #1) > This has been discussed already on a separate bug report (or I discussed it > privately with somebody else, cannot remember). > > The idea we had was to have a new section in koha-conf to list sysprefs we > couldn't edit from the UI. So it's a bit stronger than what you suggest as > only the sysop could modify them. Hmm. Interesting point. My first idea would be to keep the possibility of change by superlibrarian. If we would not want any change, we should better replace the pref by a koha-config variable?
I'd be hesitant to move certain sysprefs to the koha-conf. Many times a superlibrarian is not the sysop, and would not have access to make those changes directly when needed. I like Marcel's idea of having a customizable list of preferences that can only be changed by a superlibrarian.
The suggestion was to have a facultative and configurable list of sysprefs in the config files. The sysprefs in this list couldn't be editable from the interface (read-only).
I apologize for my imprecise wording. I would strongly oppose making this change in which sys prefs could be configured from the user interface.
(In reply to Jonathan Druart from comment #4) > The suggestion was to have a facultative and configurable list of sysprefs > in the config files. The sysprefs in this list couldn't be editable from the > interface (read-only). To be precise, thats not my idea. See comment2. I would prefer to allow changing this set of selected prefs by superlibrarian only. (In reply to Donna from comment #5) > I apologize for my imprecise wording. I would strongly oppose making this > change in which sys prefs could be configured from the user interface. At least I dont understand it anymore now :) All sysprefs are now configured via the UI. This report is about making a subset of these prefs read-only for regular users (not superlibrarians). Is that more clear?
I like the idea. For example 'KohaAdminEmailAddress' change may change all emails to SPAM :( For 'MarcFlavour' : Is it even useful to have it in UI ? We could move it to 'local usage' like 'Version'. It will be defined only during install. To add water in the mill : I'd say if a preference is really system-related we should move it to koha-conf.xml. For example 'casServerUrl', it sounds system-related like LDAP authentication that is in koha-conf.xml. Idem for OPACBaseURL. Plus add a list that only superlibrarians can edit, sort of super-preferences. PS : There is a trick actually to define a preference ready-only : define it as overwritten in Apache config via 'OVERRIDE_SYSPREF_NAMES'.
(In reply to Fridolin Somers from comment #7) > To add water in the mill : > > I'd say if a preference is really system-related we should move it to > koha-conf.xml. > For example 'casServerUrl', it sounds system-related like LDAP > authentication that is in koha-conf.xml. > Idem for OPACBaseURL. That's interesting. On one hand, Donna makes the point that a library might not always have a sysadmin available to make those changes via the CLI, so having them editable by web UI is ideal. (From a deployment point of view, it might be nicer at times to just make a data change via normal user activity in the UI rather than needing to do a full deployment.) On the other hand, as a vendor, there are times where I want to prevent all library staff users (including superlibrarians) from making certain changes, as they can break the system, make the system insecure, etc. -- What if we could add functionality for a sysadmin to lock system preferences with all sysprefs defaulted to unlocked? We could add a "locked" or "readonly" column to the systempreferences table. We could then have a little CLI script for locking/unlocking system preferences, setting system preference values.
My above idea would actually flow into another idea I've had for "hardening" Koha instances. Many of Koha's defaults are quite open and flexible, which makes it easy for anyone to use Koha. But I suspect many vendors would like to apply certain rules that make the Koha instance more secure. Originally, I was thinking about installation "profiles", which could be invoked by koha-create, but maybe a post-installation script would be easier/more flexible. While I haven't used it myself, I've been thinking about the "jboss-cli" tool that comes with the Java server JBOSS AS/Wildfly. I encountered it most recently with Keycloak: https://www.keycloak.org/docs/latest/server_installation/#_start_cli It lets you set configuration with a script. I like the idea of a "secure_koha.cli" or "vendor_profile.cli" script that you could run. A sysadmin could lock down certain system preferences, set certain values for authentication servers, email addresses, etc.
In my opinion storing security settings inside database is not good. We often copy database from a production server to a test server, where security is on purpose lower. For me the best place is koha-conf.xml, it already contains major security settings (authentication, path, ...)
(In reply to Fridolin Somers from comment #10) > In my opinion storing security settings inside database is not good. I think it's arguable about whether an Identity Provider counts as a security setting per se. Or are you referring to different settings? > We often copy database from a production server to a test server, where > security is on purpose lower. That sounds like an internal problem? What's the risk that you're worried about here? Data breach? > For me the best place is koha-conf.xml, it already contains major security > settings (authentication, path, ...) As a vendor, I like storing things in configuration files (although I hate the bloated koha-conf.xml), since they're more secure and easier to deploy programmatically. But as a consumer, we'd be removing functionality from Koha. I think that's the point that Donna is making. Unless you have the wealth to pay for a vendor or internal staff, you might not be able to configure those settings anymore. (Of course, one could argue there are many settings in Koha that already work that way.) -- Ultimately, it doesn't matter to me, as I have power. I'm just thinking about removing options from people who don't have as much power.
Bug 28998 is introducing Koha::Encryption. I'd like to use it for sysprefs that shouldn't be stored in plain text (credentials in mind).