[Zope-CMF] [dev] CMF 1.4 alpha

[Tres Seaver]

On Thu, 2003-02-27 at 10:33, Florent Guillaume wrote:
> On Thu, 2003-02-27 at 14:02, Chris Withers wrote:
> > Florent Guillaume wrote:
> > > Well, that a permission on the TI be used to control the viewability of
> > > instances seems a bit like a hack to me (although it's not without some
> > > logic I must admit). I'd much have preferred to have in the TI an
> > > explicit list of roles allowed to see the instances. Same thing for
> > > creation.
> > 
> > I disagree pretty strongly. The TI provides the meta-information for a
> > piece of content. We _could_ do what DC Workflow does and provide a
> > whole seperate system for managing role-permission mappings for these
> > two permissions, but why do that when simply setting permissions on
> > the TI could work so well? It seems pretty intuitive to me, does
> > anyone apart from you find it unintuitive?
> 
> Well the Zope security model does not care about "related" objects, the
> permissions on an object apply to the object and its methods. The
> security model does not care for the fact that the TI is
> "meta-information" on the object. That's what's unintuitive.

The "View" permission on any Zope object is the moral equivalent of the
Unix "execute" permisison;  the only sensible way to treat it on
TypeInformation objects is as protecting the "factory" / "constructor"
that the TI is a proxy for.

*Don't* try to use the TI to control visibility of the content objects; 
use the workflow states' security tabs for that (workflows already
indirect through the portal_type, and they make enforceable assertions
about the role-permission map on their instance).

> Setting permissions on the TI does nothing by itself for the instances.
> An instance marked as "not visible" by that View permission mechanism is
> still visible if you know its path.

I don't like the current use of the TI's "View" permisison to fake out
filtering in folder_contents;  I would prefer to have it just use "skip
unauthorized", with *real* security assertions assigned by the workflow.

> Let's separate the problems:
> 
> - controlling viewability of instances in a folder listing depending on
> their type: if that's wanted, that should be done by folder_contents.pt
> by checking that the TI is visible.

Nope, we should be controlling the visibility of instances via
workflow;  the folder_contents view should just omit any instances which
the user wouldn't be allowed to view if they did traverse to them (which
is what the "skip unauthorized" mechanism is for).

> That's actually what contentIds
> does. But that's not a core security mechanism.

Right;  it is only a cosmetic "pseudo-fix".

> - controlling viewability of the TI: there, View is fine. But what does
> "View the TI" mean? A user has to get hold of a TI if it wants to check 

"View" permission is "execute", not "read";  "Access contents
information" is a better map for Unix' "read".  Once you have actually
gotten hold of an instance, you *must* be able to query its TI;  trying
to protect the TI instead of the instances is a recipe for hair loss.

> - controlling creation: that's really controlling the calling of the
> constructInstance method on the TI. And isConstructionAllowed has to be
> kept in sync. So the test for a creation permission should really be in
> isConstructionAllowed.

Right.

> Ok so I guess my position is now that an "Add instances" permission is
> fine. Let's not reuse other permissions, it's not clean.

I don't think there is any sensible use for the "View" permission *on
the TI object itself* which means anything beyond the notional "Add
instances" permission.  I can live with "Add instances" if it aids
understanding, but it grates.
 
> This doesn't prevent us from adding more fine-grained guards on the
> creation, like a TALES guard. This would solve the problem of people who
> want to create only certain types in certain folders.

Sure.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com