[Zope3-dev] Initial thoughts on the Zope3 security framework

[Jim Fulton]

Guido van Rossum wrote:
> 
... 
> Mostly because each product defines its own set of permissions, right?
> Given the proliferation of similarly-sounding permissions, I question
> the wisdom of that habit.  But it's not relevant for this discussion
> (I just like to nag :-).

Nag away. The sitre manager, not the developer will be in control in
Zope 3.

> > and role-to-account mappings are adjusted (using local roles) on a
> > per-instance basis to assign privileges to particular users within
> > the context of the instance.
> 
> So a local role is (in its simplest form) similar to set-gid in Unix?
> That would imply that roles are similar to Unix group ids.  Right?
> Permissions of course are similar to the Unix 'r', 'w', 'x' bits.
> After that we run out of analogies, because the Unix stuff is much
> more restricted -- there's no way to create new permissions, which
> causes dubious overloading of permissions (like 'x' for directories
> meaning "file lookup").  Also, Unix only allows one role per object
> (the group), not counting the special roles "user (== owner)" and
> "other".  I'm guessing user/owner corresponds somewhat to the owner
> role in Zope, which AFAIK shouldn't be assigned explicitly; and other
> corresponds to anonymous, which seems to get special treatment in
> Zope.  Am I still on track?

You are pretty close. The effect of roles is superficially similar to
unix groups, however, the intent is subtelly different. A group is
a collection of users, but a role is a responsability that a user may have.
In the future we may allow users to restrict the roles that they have
at one time. We also may allow groups, as distinct from roles.

Zope has two owner concepts. There is the single owner of an 
object that corresponds directly to the unix owner. There is also
an Owner role. The owner role can be elegated to multiple principles.
 
..

> Is it common (or even possible) for the role-to-permission mapping to
> differ for two instances of the same class (not counting subclasses)?

Absolutely, even common.
 
> "Twiddled programatically" sounds like this is done at run-time.  I
> would hope that in practice this is part of a class definition or
> something (which in Python *is* runtime, but doesn't always feels like
> it), and products don't typically engage in changing the mappings
> dynamically?

Permission to operation mappings are static for a class. Role-to-permission
assignments are done by instance.
 
> > (It may make sense for the security system to solidify the
> > institution of common roles, and the ways that new roles are
> > created, to support the reuse of roles across products.  I'm not
> > sure exactly how this would be realized but the pattern is not
> > immediately obvious, and i think it's key in the coherent operation
> > and management of a site...)
> 
> On the other hand, Jim still has an opening towards capabilities in
> his security design document, and capabilities seem to do away
> entirely with roles (as well as users), substituting custom
> collections of permissions for everything.

But you need access control to generate the capabilities in the first
place, so you still need roles, permissions, and so on.
 
Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org