Forgot your password?
New user?
Document Actions
#135: Make permissions cascade down in folders
- Contents
- 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):
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:
- "The people/groups that can view this page: ..."
- "The people/groups that can edit this page: ..."
concur
I agree, people are often flabbergasted that this is not the case already. It breaks existing security memes connected to the filesystem, which our entire content structure is based on, which means that users may expose sensitive data because Plone does not meet their expectations.
It does pose problems, though
A better option could be to let the initial state of a document be informed by the state of its folder - like we do with the display mode (if you add a folder inside a folder with thumbnail view, that folder will also have thumbnail view). This presents a different can of worms, but probably a more manageable one.
I may change the PLIP slightly, but I welcome input on good approaches. I think we all know what the goal is and what the users should see as an end result.
not sure i agree
This is also part of the custom workflow we implemented, as mentioned in http://plone.org/products/plone/roadmap/134. I initially thought we should have a script run to grab the parent state and reuse it, but this poses significant problems for content types whose workflow does not match up. Alec Mitchell suggested to me that I should create a new state in each workflow which inherits security from the parent and is allowed to transition to all of the sane states, i.e. everything but rejected. This is working well for us.
Still there is an issue that other content types need a new status or some special attention. For instance we have some private Poi trackers, and I had to implement a custom Poi workflow, but I am only using a private status. I'm not sure I am quite ready to deal with Poi inheriting from above. ;)
Redacting!
I am strongly in favour of having a "new" or, actually I prefer "default" state with a "default" transition accessible from all other states. This works great for us in practice.
This fits with what our users expect
+1