Modification of System.SitePreferences

According to System/AdminDocumentationCategory

DefaultPreferences
    This topic defines site-level settings that apply to all users and webs on this site. Use this as a read-only topic. Always apply your local settings to SitePreferences 

According to System.SitePreferences (in our local instalaton)

Foswiki's default preferences are located in System.DefaultPreferences, however settings defined here have override priority and should be used for local customisations. 

I interpret this to mean that SitePreferences is expected to be editable / edited in the local installation.

I interpret this to also mean that it should be possible (i.e. expected) to attach a file to SitePreferences, e.g. the gif used for WIKILOGOIMG.

Our local Foswiki installation has locked down the System web to be read-only on the server. To me, this violates the philosophy of Foswiki. If you want to make something read-only, you do it inside Foswiki, using the appropriate ALLOW or DENY settings. At least then, the error messages make sense.

This also violates the documented use of SitePreferences.

What does the Foswiki team think of the idea of setting pub/System to 444 on the server? Can I get some support for my opinion that 444 is not "normal" and/or that this web is expected to be modifiable locally?

-- VickiBrown

Basically your sysadmin is right: the System web should be read-only. This helps to keep your install clean and upgrade-safe. From what I see the discrepancy with what you read in the documentation is, well, "only" a documentation issue. Could very well be that these two locations for default preferences, System.SitePreferences and System.DefaultPreferences are one too much.

Best Practice is to never touch any of those two as well as none of the other topics in the System web. All configuration of your custom site-level preferences go into Main.SitePreferences. That's the location meant to override anything configured in System.SitePreferences (and System.DefaultPreferences).

There are some plugins that still rely on configuring preferences in the plugin's System topic. That's a problem when upgrading these plugins of course, as well as a performance problem. More modern plugins add a $NO_PREFS_IN_TOPIC = 1 setting to their perl stub to tell the foswiki core not to look into the plugin's System topic for more preferences.

IMHO, even better is to move settings totally off the preference system and move them completely into LocalSite.cfg and managed by the configure application. Best candidates are those settings that never or only rare have to be adjusted during the lifetime of a foswiki as they only have to be touched once during initial installation.

Big advantage of settings in LocalSite.cfg vs settings in the preference system: they are evaluated only once and are cached during the lifetime of a persistent perl backend (which I assume you are using!).

Of course some settings belong into the wiki system so that they benefit from "wikiness". These are mostly located in WebPreferences giving teams of a web some level of control about their web customizing it to their needs. These are look&feel things like logos, descriptions, skin settings, view templates, DataForm definitions, or useful shortcuts for content authors.

-- MichaelDaum - 11 Nov 2011

Just an observation: It should be Main.SitePreferences.

-- LarsEik - 11 Nov 2011

Could very well be that these _two_ locations for default preferences,System.SitePreferences and System.DefaultPreferences are one too much.

If the docs are incorrect, then System.SitePreferences should not exist. If the docs are correct, then it's not "one too much".

It's probably simplest to state that the docs are incorrect, fix them, and make System.SitePreferences go away.

(I'm still not convinced that changing back-end Unix permissions to 444 is the best way to "lock" the system web. The error is too easily misunderstood. But that's a different issue)

-- VickiBrown - 11 Nov 2011

There are only two System configuration topics

• System.DefaultPreferences
• Main.SitePreferences

I can't find any references to System.SitePreferences anywhere in the System web. It is referenced either explicitly as Main. or %USERSWEB%, or it's non-linking SitePreferences. The raw code from that first example you quoted at the start of this topic is actually coded as a %USERSWEB reference. See: http://trac.foswiki.org/browser/branches/Release01x01/core/data/System/AdminDocumentationCategory.txt#L13 If you have a specific documentation reference that is pointing to the System web, please add it and we'll get it corrected.

As far as the actual topic goes, if a System.SitePreferences topic exists in your wiki, it was probably locally created. I've gone back to the import of TWiki code into Foswiki, and even back then it was in the Users Web (Main) and not the System (or TWiki) web. However, the local topic can be indeed be stored in the System web, as the fullly qualified topic name is set in the LocalSite.cfg, inherited from Foswiki.spec as $Foswiki::cfg{LocalSitePreferences} = '$Foswiki::cfg{UsersWebName}.SitePreferences';. If your active SitePreferences topic is in your System web, then the LocalSite.cfg has been changed from the default.

In regards to locking the system web using the file system, I'd call it a belt and suspenders solution. The System web is already locked down to the AdminGroup by default. So further protecting via the file system is another layer of protection from the Admin group. However I don't believe our unit tests fully exercise the impact of a read-only file system, so you are probably on somewhat uncharted territory. But again since it's restricted to the Admin group, it probably is not any sort of a significant exposure. And since it's write protected, I can't imagine it causing any issues.

-- GeorgeClark - 12 Nov 2011