[Zope-Coders] Re: "Anonymous" role is pretty bizarre?

[Chris McDonough]

On Mon, 2004-03-22 at 17:21, Tres Seaver wrote:
> > It's the only role that is meant to apply to a single system user and
> > one of two (with Authenticated) which cannot be granted to normal
> > users.  Think about it.
> 
> Both of those roles are logically groups to whom permissions are 
> assigned:  the 'Anonymous' role is actually an 'Everyone' group, with 
> special-cased optimizations based on that fact littered throughout the 
> code.  The 'Authenticated' role is really a group consisting of 
> 'Everyone' minus the one-and-only 'Anonymous User'.

That's the way I'd prefer to think about it too.  I hope we can get
there.  I'm not sure we can kill off the anonymous role because of b/c,
but having dynamic groups in Zope 2 would make it technically possible. 
The special-case checks probably make things faster, but if I think it
would make it clearer to be able to grant a local role (or the
equivalent through "permission sets") to either the Everyone group or to
the Anonymous user directly.

> Getting the terminology straght is hard, especially after we have all 
> bent our brains not to fight with Zope's machinery.
> 
>    'Principal' -- an identifiable user, or group of users, to whom
>      privileges are granted.
> 
>    'User' -- a single principal, associated with a request.  Each request
>      has exactly *one* user, who may be the "nobody" user.

FWIW, I am all for this, but Jim and Steve's "Use" discussion that
mentioned multiple principals being associated with the same request on
the Zope3 list belies this.  I never did quite understand that, but I'm
resigned to not understanding it, so that's ok. ;-)

>    'Group' -- a collection of principals (perhaps including other
>      groups!)
>
>    'Role' -- an abstraction representing the granting of one or more
>      privileges to a given principal.

In Zope 3, I think this is called a "grant" instead of a "role". 

>    'Permission' -- a single privilege, defined by the software developer.
> 
>    'Permission set' -- a rolled-up set of permissions, designed to be
>      presented as a single chunk in the UI.
>
>
> <pre class="sop-to-mail-readers-with-non-monospace-fonts">
> 
>        +---> Principal<-------->Role<-------->Privilege <-------+
>        |  *      ^     *      *      *      *     ^      *      |
>        |        /_\                              /_\            |
>        |         |                                |             |
>        |         |                                |             |
>        |     +---+----+                    +------+------+      |
>        |     |        |                    |             |      |
>        +-<>Group    User            Permission  PermissionSet<>-+
> 
> </pre>
> 
> In Zope, roles are often warped into either 'groups' or 'permission 
> sets', when in fact they are a third thing altogether (this confusion 
> arises largely because classic Zope2 has neither groups nor permission 
> sets).

I think for all intents and purposes for Zope 2 that roles really are
permission sets.  At least that is how I think of them.  I don't think
much has changed in Zope 3, but I might be wrong.

> Zope3 has already disentangled this mess to some extent;  Jim has 
> expressed some hope that we might be able to migrate its cleaner model 
> back into some version of Zope2.  Zope3 does allow for grants of 
> privileges "directly" to principals, with no explicit role;  it makes 
> this choice because many people find such grants "natural".  I would 
> prefer to model that grant as being made a an "eponymous" role, but 
> maybe I am just fussy. ;)

The good news is that the only security definitions "baked in" to Zope 3
are the bare minimum necessary: principals and permissions.  The rest of
the stuff in the default declarative security implementation can be
replaced.  You can replace the default declarative security
implementation with an implementation that doesn't even have roles,
which is pretty nice.

> OTOH, the "Anonymous" role which this sub-thread is about is almost such 
> a role, so perhaps not.

I'd personally rather not need to create the eponymous role, and I'd
particularly like to see no "system" eponymous roles.  When an eponymous
role gets created for system purposes (like Anonymous is now), it can't
be deleted by a manager.  And I think it's important for people to
understand that they as system managers are in control of roles and
should be able to create them and delete them as they see fit.  I think
having this one that they can't delete and that they didn't make just
sort of breaks their expectations.

You can argue the same thing about "Everyone", "Authenticated" and
"Anonymous User", but I think these concepts are more accepted in
general due to their use in operating systems like Windows NT, Netware,
etc.  And if you model "Everyone" and "Authenticated" groups as "dynamic
groups" (as I think they should be modeled), these could potentially
also be redefined or even deleted (and it should be possible to do so),
so I think that leaves the one super-special "Anonymous User" that
cannot be redefined or deleted.  This is also why I'd like to be able to
grant local roles to the Anonymous User, because it makes sense (at
least to me) to leave everything else configurable and redefinable, and
there might be no other way without keeping the special Anonymous role
to be able to unequivocally grant permissions to the Anonymous User in a
particular environment.

FWIW, as far as Zope 3 permission-granting goes, I can't think of a
reasonable case where I'd want to grant a single permission to a group
or user, but I can think of cases where I might want to *deny* a single
permission (out of paranoia) from a user or group in a place even though
he/they might otherwise have it by virtue of other grants, so I think
being able to do this on this kind of granular level is very nice.  I
don't know if it's reasonable to introduce this granularity into Zope 2
though, at least without a strong committment to updating the existing
documentation.

- C