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

[Guido van Rossum]

> > Ah, that *does* clarify things.  So role names and role-to-permission
> > mappings are totally global and central?
> 
> Not quite.-)
> 
> Each object can inject its own role-to-permission mappings,
> including the choice to acquire each mapping from its context
> (container).  You've probably seen the "security tab" ZMI screen -
> it's a matrix for making those assignments (including the "acquire
> from context" choice).

Yes.  Unfortunately that screen suffers from too many checkboxes and
not enough information.  But I believe that's a well-known fact. :-)

> I think that, ideally, it's relatively rare to create new roles,
> while role-to-permission mappings are typically adjusted on a
> per-product basis,

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 :-).

> 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?

> Here's how i see it, in practice.
> 
> There's a benefit in having common role names across a site, so that
> someone can be assigned a role high up to get privileges accorded
> that role within many different contexts.  A prime example is the
> "manager" role.

Hm, everybody always seems to use the manager as a prime example of
the userfulness of roles.  Since in practice the manager role is
almost omnipotent (as I found out when I wanted to create a PSF Board
Wiki that the PSF webmaster couldn't read), I'm not sure that it's
such a great example.

> Within the context of a folder, manager may be able to delete and
> add stuff regardless of the folder's ownership, while within the
> context of a collector, a manager may be able to adjust supporter
> settings and access private issues collector-specific duties.  This
> way, someone with manager role in the root of the site gets
> manager-oriented privileges in all contexts that follow this
> convention.  Further, the collector reuses the "reviewer" role for
> supporter duites.  "Reviewer" has the authority to approve
> publication in the context of documents, in the collector they have
> authority to handle issues...

I find this latter example a little too cute for its own good.  It may
be totally inappropriate for a particular site's policy.  Also it
suggests that maybe it's too hard to create new roles -- just as it is
too easy to create new permissions...

> Role-to-permission mappings associate the privileges with the roles,
> and are generally twiddled programatically by the product across its
> instances.  Role-to-account mappings - using local roles - are
> adjusted by the product as role-assignments shift within the
> instance.

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

"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?

> (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.

> Hmm.  The canonical use could be "rule X obtains in situation Y".  I
> don't think it would work to say "rule X can be obtained in
> situation Y".  Rather, "rule X holds..." or "rule X applies...".
> (For me, "obtains" is significantly less ambiguous than the other
> choices, so i find it appealing...)

Maybe I can get used to it.

--Guido van Rossum (home page: http://www.python.org/~guido/)