Feature Proposal: Implement "additive" Topic level ACLs

Motivation

Currently Topic level ACLs completely override web level ACLs. For ex,

• ALLOWWEBVIEW = JoeUser
• ALLOWTOPICVIEW = FredUser

results in JoeUser being unable to view the topic. This has been a fundamental design of Foswiki ACLs since the beginning.

The TWiki project has seen the need and implemented Additive ACLs, where a Topic ACL can be specified to "add to" the Web level settings. This has benefits where a site needs to relax ACLs on individual topics, but don't want to be forced into editing all topics whenever Web level ACLs are changed.

Description and Documentation

The TWiki implementation is described as:

You may want to allow or deny access to a topic in addition to the ALLOWEB* or DENYWEB* specifies. In that case having + as the first non-space character of ALLOWTOPIC* or DENYTOPIC* has that effect. For example, the following setting allows view by MarketingExecGroup in addition to the people ALLOWWEBVIEW allows.

• Set ALLOWTOPICVIEW = + Main.MarketingExecGroup

We have a couple of implementation choices:

• Add it to the Foswiki::Access::TopicACLAccess as a default feature.
• Create a new alternative AdditiveACLAccess implementation

It appears to be a very straight forward implementation in TopicACLAccess - if the ALLOWTOPIC setting begins with a +, prepend the corresponding ALLOWWEB setting.

• This is purely additive
• Applies to the entire setting. It is not per user.
  • eg. you cannot do JoeUser +FredUser -BadUser

As this feature does seem to have some reasonable usefulness, and appears relatively simple. I think incorporating it into the current ACL implementation would be preferable to creating a new implementation.

We could also make it configurable. {AccessControl}{AllowAdditiveACLs}.

Examples

• ALLOWWEBCHANGE = WebMaintenanceGroup
• ALLOWTOPICCHANGE = + JoeUser

Anyone in the WebMaintenanceGroup can edit the topic, as can JoeUser.

Impact

No impact to existing topics / installations.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 06 Feb 2017

Discussion

I'm not 100% sure that this is the right solution. What my user could use is a per web AdminGroup, where certain users could override all the ACLs in a web, without giving those users complete site-wide admin privileges. It does seem useful to have additive ACLs, but you would still need to edit every topic in the web, adding the +, to get the desired results.

So while this might be desirable to keep some backwards compatibility, it doesn't really solve the issue I've encountered.

-- GeorgeClark - 06 Feb 2017

A preference setting ADDITIVETOPICACLS set to true / enabled, could make this a default behavior per the normal preference hierarchy. Another example for example, in the Usersweb, it might be reasonable to allow the group that "approves" registrations to have more generous access to user topics.

-- GeorgeClark - 07 Feb 2017

In general the idea is not bad even though it doesn't really make ACLs more understandable. What people normally do is to add JoeUser to the WebMaintenanceGroup. He might get more access than required but that this kind of problem didn't really arise in the real world as far as I've seen.

Adding this feature to the current ACL system might be easy. Yet I'd prefer to only enable it via a configure switch if backwards compatibility to TWiki is a requirement.

I'd call it {AccessControlACL}{EnableAdditiveRules} given we already have {AccessControlACL}{EnableDeprecatedEmptyDeny} ... and default to $false.

-- MichaelDaum - 07 Feb 2017

This is ready for evaluation for 2.2, in the Item14342 branch.

-- GeorgeClark - 14 Mar 2017

Commenting is disabled while not logged in