Ticket #9548 (closed PLIP: wontfix)

Opened 6 years ago

Last modified 5 years ago

Make permissions cascade down in folders

Reported by: dukebody Owned by:
Priority: minor Milestone: Future
Component: General Version:
Keywords: Cc: servilio

Description

 http://plone.org/products/plone/roadmap/135

A change in the behaviour of security so that restricting a folder automatically restricts the folders below it.

Proposed by

Alexander Limi

Seconded by

Joel Burton

Proposal type

Architecture

State

being-discussed

Motivation

Historically, if you made a folder private in Plone 2.0 - everything beneath that folder would be inaccessible to people that didn't have permissions to view that folder. This was a result of an unintended implementation detail: since you didn't have the permissions to view the elements in the breadcrumbs/navigation tree, Plone would present you with an authentication dialog. (The object was still accessible if you knew how to access it without the surrounding UI elements, though)

In Plone 2.1, this bug was fixed, since we now use the catalog for looking up that behaviour. The end result is that objects now have everything governed by their workflow state, and that you have to change the security manually on every item inside a hierarchy - and all new items added will be unprotected until this is done.

The current behaviour is a significant security risk in that people expect permissions to cascade down into their hierarchies. They very often just make a top-level folder "private", and assume that all the content below it is protected, which it is not.

Proposal

The workflow should be changed so permissions cascade down the hierarchy.

Implementation

Most likely adopting the changes to the workflow detailed in the following how-tos would be sufficient (they are largely similar, but including both for completeness (and to make sure we update these when/if the default behaviour changes):

  • Making permissions cascade/inherit in a hierarchy
  • How to make a complete folder structure private

Deliverables

  • Changes to the workflow
  • Unit tests demonstrating the new behaviour
  • Deprecation of the referenced how-tos to only be valid for Plone 2.0/2.1/2.5

Risks

  • This is security- and acquisition-related, so obviously there will need to be some good tests to make sure it works the way we intend it to.
  • There is also a risk that somebody is depending on this behaviour (although that would be very rare in my experience with customers) - this can be alleviated by a how-to that demonstrates how to get that behaviouor back.
  • The "who can see what" question would be harder to answer (even though the color coding of the nav tree helps a lot here) - this could be alleviated by adding something to the Sharing page that listed something like:

o "The people/groups that can view this page: ..." o "The people/groups that can edit this page: ..."

Change History

comment:1 Changed 6 years ago by servilio

  • Cc servilio added

comment:2 Changed 5 years ago by rossp

  • Status changed from new to closed
  • Resolution set to wontfix

PLEASE READ THIS AND RE-OPEN VALID PLIPS!

As we launch the new PLIP process we'd like to see which PLIPs:

  • are still appropriate/needed
  • still have owners/proposers/champions
  • still have available implementers

If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.

comment:3 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.