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

[Ken Manheimer]

On Mon, 10 Dec 2001, Guido van Rossum wrote:

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

Yes!

In fact, i believe that the things we're discussing here begin to
approach the real issues behind that clutter.  The questions are not
about presenting the myriad choices in a palatable way, but rather,
they're about rationalizing the system so fewer, more intuitive (or at
least, more self evident) choices are offered.

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

Permissions correspond to authority for specific actions in an object
- it exposes a policy handle on the actions.  This handle enables both
product developers and site administrators to dictate which roles can
do which actions, by adjusting the mappings of permissions to roles.

My read is that, since the permissions expose product-specific actions,
they need to be unique, in as much as the actions are unique.  When
viewed with respect to a product where they pertain, they're not so
overwhelming.

There are permission which apply to many products - eg, FTP and WebDav
access controls, however.  On thing leading to the proliferation is
these general permissions.

Maybe the component model will enable reduction by increasing the
separation of responsibilities for various things.  For instance, FTP
permissions could be associated with the FTP 'view' component of some
content, instead of being on the content itself.  This way, the
permissions on the content wouldn't grow proportionally to all the
ways the content could be used, just according to its own, particular
actions.

(I believe another big reason for the proliferation is promiscuity in
the trickle-down of all permissions relevant to the containing
context, even when the permissions are not applicable to the object at
hand.  I suspect *this* is a UI issue - better filtering for relevant
permissions is necessary.  I'm not acquainted with the architecture
here, though.)

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

I don't think so.  Local roles really are about identifying the roles
that various accounts have with respect to the object, while setgid is
about endowing particular permissions to *anyone* using that
executable - so everyone using it can access a file, or the network,
or some resource that anyone using the object (well, executable) will
need.

There's something called proxy-roles in zope which does correspond.
IIRC, it identifies a role that that is imposed on any account that
runs a method - in order to enable access to some resource, etc, as
with setgid.

> That would imply that roles are similar to Unix group ids.  Right?

At the limit, yes.  I think unix groups and zope roles are so
different, though, that a corresondence between the two isn't very
meaningful.

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

I think unix permissions and zope permissions *are* similar in
principle, more so than unix groups and zope roles.  As you suggest,
there are basically three permissions in unix, while zope's set is
extensible, according to the actions you can take on an object.
(Considering that files have a limited repertoire of things you can do
with them, as objects, that makes sense, compared to the infinitely
more diverse behaviors of zope objects.)

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

Hmm, if i had time i'd be interested to investigate.  I may have
screwed up in development of wiki regulations - specifically,
neglecting the 'manager' convention!

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

I'm not sure.  One possibility that makes some sense to me is for zope
to provide a more canonical collection of roles to build on.  Product
implementers and site administrators would then have a predictable,
shared range of things to target - aiming the functionality, on the
developer side, and policy, on the adminstrator side, at that more
clearly defined set.  This set could still be extensible, for those
occasions when something truly new is truly needed, but people would
want to create new ones only with good reason, because they'd be
sacrificing the generality of the canonical ones.

I suppose the question comes down to, "does it make sense that
enabling someone with privileges to approve document publication in
some area also mean they have privileges to handle collector issues
within that area"?  (Note that the locality of local roles means that
you can have different assignments of the reviewer role in different
areas.)

If you want to preserve complete separation between every set of
permissions, then you need to have a unique role for every set.

I'm beginning to be convinced that that separation is usually _not_
necessary, and the systematic consolidation of roles to a canonical
set would make life simpler while still providing as much discretion
as people need.  Maybe a measure that allows people (like site
administrators) to inhibit someones roles within a context would be a
better solution when people need that last degree of discretion.

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

Yes.  That's the purpose of the "security tab".  It enables site
administrators and object owners (and whoever else has the "Change
permissions" permission, in context) to adjust access to actions on a
per-instance basis.  People would typically revoke an objects 'View'
permission from the anonymous role to prevent non-authenticated users
from viewing the object.  Doing so in the site's root folder would
mean inhibiting access to the site - except in subobjects that
explicitly endow that permission to anonymous.

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

Yes!  It's common to use the "security manager" to "declare" the
association of methods with permissions, in the class definitions of
objects.  The assignments are executed as part of the definition:

  from AccessControl import ClassSecurityInfo, ModuleSecurityInfo

  class Collector(SkinnedFolder):
      [...]
      security = ClassSecurityInfo()

      security.declareProtected(AddCollectorIssue, 'add_issue')
      def add_issue(self, ...)
          """Create a new collector issue."""


For details, see:

  http://www.zope.org//Wikis/DevSite/Projects/DeclarativeSecurity/ZopeSecurityForDevelopers

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

I like what i understand about capabilities.  I have to admit, it's
taken me a long time to get the bare grasp i have the security system
i'm using, i have a way to go to begin to understand how capabilities
would fit in.  The little i have understood in various discussions is
promising - but that understanding hasn't stuck, i couldn't repeat any
of it without looking it over again.

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

:-)  Conversely, there actually was a message i sent out today where i
used "holds" instead of "obtains", despite my preference...  I'm sure
i'll revert to old habits, but it's good to occasionally make gestures
against my own stubborness...-)

Phew, this took longer than i intended.  I hope this continues to shed
some light - it helps me in thinking things through to write it out,
so i think my own understanding (and lack thereof) is clearer...  I
don't pretend to have the answers, or even have the best handle on the
existing system, but i believe that the issues in this discussion get
at the crux of the matter.

-- 
Ken
klm@zope.com