Feature Proposal: Access controls should inherit from Main.SitePreferences and System.DefaultPreferences

Motivation

ACLs are confusing enough, without making them look like PreferenceSettings but then have them inherit differently.

Description and Documentation

• Currently, ACLs only inherit up to the root web. Let's add Main.SitePreferences, System.DefaultPreferences into the hierarchy.
• Accordingly, comment-out the (ALLOW|DENY)WEB(CHANGE|RENAME|VIEW|...) settings in the _default template web. The most common failure mode I've observed is that users create a subweb from _default which stomps all over the parent web's settings, whereas they expected the subweb to have the same ACLs as its parent.
• Move the commented-out settings in _default.WebPreferences into System.DefaultPreferences.
• Update System.PreferenceSettings and System.AccessControl documentation
• Change the web creating code to not magically insert default ACL prefs into WebPreferences topic if the template web lacks them.

(ALLOW|DENY)WEB(FOO) should inherit as follows (first to last):

• WebPreferences in the topic's web
• WebPreferences in the topic's parent web (recursively up to the root web)
• Main.SitePreferences
• System.DefaultPreferences

Examples

Impact

• Foswiki::Access
• Foswiki::Access implementations such as TopicACLAccess and MongoDB (others?)
• Foswiki::UI::Manage; there's some hard-coded stuff which forces WebPreferences to contain ACL settings in the newly created web if they're not explicitly set in the web template (thanks GeorgeClark)
• This does not impact existing content, existing webs already have explicitly set ACLs in their root webs due to the fact they can't inherit from Site or DefaultPreferences.
• This DOES impact the existing userbase when they create a new web from _default. Instead of getting a copy of some probably inappropriate ACLs, they will instead inherit from the parent web or from Site or Main.DefaultPreferences. I think this is more correct behaviour anyway, and those experienced users who are used to having to make corrections on the ACLs of newly created webs will not be inconvenienced - .

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

This needs lots of tests. The current coverage is depressingly minimal.

Related topics

AccessRightsChange	Change Access control to avoid build in security issues	ParkedProposal
PermissionsChange	Changing Access Permission	DiscardedProposal
PluggableAccessControlImplementation	Pluggable Access Control Implementation	MergedToCore
QueryAccessControls	It should be easier to get a definitive overview of the Access Controls present on a given topic.	UnderInvestigation
RefactorACLCheckOnResultSetAsFilter	Refactor ACL Check and Pager on ResultSet As Filter	MergedToCore
SynchroniseInlineAndMetaPrefs	In-line * Set preferences should always match META:PREFERENCE, and vice versa	UnderInvestigation
Item10078	Separate, enhance, and test documentation of ACL preferences	Closed

-- Contributors: PaulHarvey - 15 Jun 2012

Discussion

This seems so obvious to me that I'm concerned I'm missing something fundamental. Explaining to users that preference settings inherit a certain way, "except if it's an access control... by the way don't forget new subwebs will probably have incorrect ACLs set" is incredibly tedious. Not to mention if they decide that their project should have different access controls, they have to work through all their webs one by one (or rather, they change the root and then complain to me when things don't work as they expect).

I hope more experienced devs can tell me what's wrong with this idea.

I want to scope out the scale of work required (90% effort will be tests, I think) and if it doesn't completely overwhelm me, and assuming I can get the work done I'd like to consider including this for 1.2, but we shouldn't block 1.2 for this by any means.

-- PaulHarvey - 15 Jun 2012

This proposal opens a whole can of worms. Although the work seems obvious to me, GeorgeClark and SvenDowideit are rightly worried about proving not only correctness, but also proving we understand what the existing code does, and therefore proving what impact this has on existing users.

Their second concern seems to be about the general philosophy of relying on inheritance for ACLs at all. "Too much indirection" syndrome.

I hope that we can address by, as SvenDowideit suggested, making a VewTemplate helper as he did for the Groups UI. We could make something for WebPreferences topics which use VarSHOWPREFERENCE to clearly show what the ACL variables are set to, and where they were set.

http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2012-06-15,Fri&sel=112#l108

Sven also asked me why WebPrefsPlugin didn't help us out. It's again because of "too much indirection" syndrome. In the end they didn't find the UI terribly informative, - they much preferred an exhaustive list of who could view and who could edit. This obviously isn't possible for large sites using large LDAP trees, but it's what worked for us (and paid for a confluence plugin that did the same).

-- PaulHarvey - 15 Jun 2012

I think there are two separate issues here:

• Inheritance of WEB level ACLs from a new Site level defaults for the ALLOW / DENY WEB settings
  • When they are undefined in a WebPreferences topic
  • Can the setting be FINALIZED at the site level, preventing changes at the Web level.
• Defaults populated into the WebPreferences topic when a new web is created.
  • Copied from the template WebPreferences topic identified in the create dialog
  • And currently hard-coded in Foswiki::UI::Manage

I support that Inheritance should be possible at the web level. Behavior of FINALIZED site level settings needs to be defined.Also relationship to the ROOT* settings that apply when creating root level webs.

For the populated defaults, it probably needs to be better defined as well

• Eliminate hard-coded defaults in Foswiki::UI::Manage
• If template web has active settings, honor them. Admin can remove them from the templates if desired.
• Add a checkbox - Set Access Control for this web explicitlyfrom the inherited settings
  • Parent web if available
  • Root web settings (?)
  • Site Preferences
  • Default preferences

-- GeorgeClark - 15 Jun 2012

Based on my desire to avoid special cases, I think ACLs should be finalizable at any level where ACLs are allowed to be set (which is currently the case).

FINAL preferences are annoying because it creates opportunity for confusion. A new WebPreferences UI as per Sven's Group UI might help here.

-- PaulHarvey - 15 Jun 2012

In terms of implementation, you hit the nail on the head above; ACLs are not the same as preferences, and the merging of the mechanisms for handling them has created much pointless complexity in the code. ACLs are handled quite differently to preferences, and including finalisation and site preferences in the evaluation order for ACLs would make it significantly more complex, too.

Can we think creatively how to decouple ACLs from preferences completely?

-- CrawfordCurrie - 15 Jun 2012

Paul, in the IRC logs I note that you are initially prompted in this direction by users creating sub-webs using _default and stomping all over the higher level web ACLs. If creating a web with _default (or indeed any _templateWeb) has intelligence to say:

• Creating a root web then use defined web ACLs
• Creating a sub-web then do not set any web ACLs

would not that solve your issue?

In my VDBI stuff I have a separate ACL table to improve performance and naturally create a Foswiki::Access::VDBI. My first reaction was: oh no not more ACL complexity After some reflection it would just be another level of inheritance. Nonetheless I'd prefer to avoid it.

I'd certainly like this clarified somewhat, especially when and where FINAL web ACLs make any sense and what they mean. When first creating my ACLs for VDBI, I simply ignored those as specified in each web as they are implied by the DOCs. My question became what would the absence of a web FINALIZE mean at the lowest level web? I can now see some value in FINALizing a web at least one level above another web, i.e. setting a web-preference in a lower level web could make some sense. Conversely, anyone with the authority to create those sub-webs or change their ACLs should surely be trusted/competent enough to be able to adjust the ACLs. Therefore, why not treat ACLs quite independently from PREFs?

-- JulianLevens - 15 Jun 2012

Avoiding worthless defaults would be an improvement, but I fail to see how repeating the same setting 51 times (that's how many root webs we have) much less 166 times across all webs (from which I'm still surgically removing redundancies) lends itself to helping out the average wiki admin. This is avoidable tedium which creates maintenance hassle.

Granted, we have many such things in Foswiki which making administrating Foswiki tedious; this one just really grates me at the moment - especially because I'm trying to hand over day to day administration to content owners, and explaining this crap reflects poorly on our product.

JulianLevens, I'm wondering if your reaction is actually due to complexity concerns, or rather proving correctness? If I was able to create a thoroughly comprehensive test suite which could validate VDBI against, would that make you feel better about it?

-- PaulHarvey - 15 Jun 2012 - 11:31

Actually, repeating the same setting 51 times reminds me.

The way we currently populate webs with copies of a set of topics is stupid. its a legacy of TWiki pre-view/edit templates. Copy on edit is pretty simple to implement in a store (yes, I did it in twiki) - and the webprefs we existance marker topic should really be a view/edit template driven wikiapp.

Once we make a UI that is abstracted from the serialision, pluggable ACL's (which already exist in 1.2.0 trunk) become even more simple.

oh crud. adding me to dev's, as i've implemented all the bits previously, it just needs tying together (and then UI people and 'finishers').

-- SvenDowideit - 16 Jun 2012

PauHarvey: a really comprehensive test-suite would of course be great.

My other concern is that while I have a design worked out to build the ACLs into a table for fast lookup. Basically at a web level I would have an ALLOWWEBVIEW (DENYWEBVIEW etc) row in a table repeated for each user/groups in the list. A single topic has potentially 8 sets of entries per mode (DENYTOPICmode with & without entries; ALLOWTOPICmode with and without entries, DENYWEBmode with & without and ALLOWWEBmode with & without). Each sub-web in the hierarchy (and by extension system and site defaults) would add another 4 sets for each topic. To emphasise a set could be many entries depending on how many users/groups exist on each accessTOPICmode.

Careful use of indexes and using group-wise minimum to take advantage of index skip-scan may still work out fast and from a performance point of view all of the above may not matter. I also have the alternative to collapse all web-based access to a single set of 4, making sure I carefully re-write all the rules whenever changes are made to preferences in the web-hierarchy.

I have to do this work anyway because of sub-webs, so I can accommodate it. It's really my job to make it fast — somehow.

Conversely, we do not want an ACL design that completely destroys any hope of fast access, and this suggestion will only slow it down a fraction.

All in all I would like the rules to be clearly defined ref ACLs. In particular does FINAL mean anything for them? I would prefer that for ACLs the FINAL rules are FINAL as specified by the community and cannot be changed locally. The How Foswiki evaluates ALLOW/DENY settings section makes no mention of how FINAL setting could influence the web/topic ACL rules. Adding ALLOWTOPICVIEW et al to FILEPREFERENCES effectively becomes documentation.

I have just started looking at the prefs/ACL code and at first blush as ACLs piggy back on the prefs then I would imagine that FINALPREFERENCES would be honoured, but what would that mean in practice if various accessTOPICmode prefs were removed from FINALPREFERENCES - how would ACLs then operate? Would such a practice have any benefit anyway? Does any FW site take 'advantage' of such an ability. What are the rules/meaning in having FINALPREFERENCES set at a high-level web compared to a low-level? Would the low-level web preferences be ignored? In the absense of any FINALPREFERENCE for web ACLs, would setting an ALLOWWEBVIEW in a topic be honoured in that topic irrespective of whether or not that's useful? I would also assume that a sub-webs ACLs would obliterate any higher up (non-FINALIZED) ACL settings — and it's not some sort of merge process.

If while writing a test-suite you answer and clarify and document all of this then I would be very grateful.

For now, in VDBI I may well ignore FINALPREFERENCES for ACLs and although in practice that may prove to be correct behaviour. I would dearly love to know that it is completly correct.

-- JulianLevens - 21 Jun 2012

Having just encountered a site where CommentPlugin access rules was changed from CHANGE to COMMENT, this proposal makes a lot more sense. In terms of extended ACLs, there is no default. So access is granted. It would have been very handy to just set a default DENYWEBCOMMENT = * rather than update ever web.

-- Main.GeorgeClark - 16 Nov 2015 - 20:52 Developer is no longer contributing. Changed status to 'ParkedProposal'

It appears this proposal was partially implemented.

-- Main.CrawfordCurrie - 11 Jan 2016 - 18:00

Commenting is disabled while not logged in