[Zope3-dev] Permission granularity/permission groups

[Jim Fulton]

Roger Ineichen wrote:
> From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
> 
>>[mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
>>Behalf Of Jim Fulton
>>Sent: Wednesday, February 09, 2005 8:47 PM
>>To: dev at projekt01.ch
>>Cc: zope3-dev at zope.org
>>Subject: Re: [Zope3-dev] Permission granularity/permission groups
>>
>>Roger Ineichen wrote:
>>
>>>Hi
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
>>>>[mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
>>>>Behalf Of Jim Fulton
>>>>Sent: Wednesday, February 09, 2005 6:40 PM
>>>>To: Garrett Smith
>>>>Cc: zope3-dev (E-mail)
>>>>Subject: Re: [Zope3-dev] Permission granularity/permission groups
>>>>
>>>>Garrett Smith wrote:
>>>>
>>>>
>>>>>As I define the permissions for my application, two things 
>>>>
>>>>strike me:
>>>>
>>>>
>>>>>- I'm wanting to group permissions -- e.g. 'manage content' 
>>>>
>>>>might be a
>>>>
>>>>
>>>>>permission that also includes 'add content', 'modify content', and
>>>>>'delete content'.
>>>>>
>>>>>- Because permission grouping is yet another complexity layer, I'm
>>>>>thinking that creating fine level permissions is better 
>>>>
>>>>than generalized
>>>>
>>>>
>>>>>permissions (i.e. scrap 'manage' in favor of separate 
>>>>
>>>>'add', 'modify',
>>>>
>>>>
>>>>>and 'delete') -- I can then get permission groups using roles.
>>>>>
>>>>>So my questions:
>>>>>
>>>>>1 - Do people generally agree that permission groups is 
>>>>
>>>>unneeded because
>>>>
>>>>
>>>>>the same effect can be accomplished using roles (and 
>>>>
>>>>perhaps otherwise
>>>>
>>>>
>>>>>bad for complexity/performance reasons).
>>>>
>>>>Assuming that you don't let users grant permission sto roles, then
>>>>I think that roles is an acceptable short-term alternative to 
>>>>permission
>>>>groups.  I don't have time to implement permission groups 
>>>>anytime soon.
>>>>
>>>>Someday, I'd like to use roles for something a little different than
>>>>permission groups, but I don't know if I'll every get 
>>
>>around to that.
>>
>>>>
>>>>>2 - When defining permissions for an application, is it 
>>>>
>>>>better to start
>>>>
>>>>
>>>>>with fine level permissions -- i.e. try to get everything 
>>>>
>>>>right from the
>>>>
>>>>
>>>>>start? Or is there a good strategy to start with more general
>>>>>permissions and migrate an app later as needs require?
>>>>
>>>>I'm inclined to think starting general is better.
>>>>
>>>>
>>>>
>>>>>My concern in question 2 is that I'm not sure what permissions are
>>>>>'correct' and would prefer to start at a high level and 
>>>>
>>>>move to finer
>>>>
>>>>
>>>>>level permissions over time.
>>>>
>>>>Right
>>>>
>>>>
>>>>>But won't this imply complicated upgrade
>>>>
>>>>>scripts over time?
>>>>
>>>>Only if you let users grant to permissions directly.
>>>>
>>>>Give the current permissions+roles scheme, I'd like
>>>>to remove permissions from the current granting UI.
>>>>(This would make a much better UI possible, BTW.)
>>>>
>>>>If user's can only grant to roles, then all you need
>>>>to do when you change permissions is to adjust the
>>>>role-permission map as necessary.
>>>
>>>
>>>A permission group or role is the same, it's just 
>>>the name that doesn't fit?
>>
>>In theory, they are different.  In practice,
>>as currently implemented, a role is just a group
>>of permissions.
>>
>>
>>>Both a role or a permision group are contained or mapped to
>>>principals and declare which permission they have.
>>>
>>>Or I'm wrong?
>>
>>I would word it differently.
>>
>>- Roles can be granted to users
>>
>>- Permissions can be grantd to users
>>
>>- Permissions can be granted to roles
>>
>>You can think of this as "mapping", but I prefer the
>>term grant.  Actually, if we were using roles as "roles",
>>rather than permission groups, I would say that roles are
>>assigned to users. Theoretically, roles are "jobs" or positions
>>people have relative to the system.
>>
>>
>>>If I understand you correct, we shouldn't map permissions
>>>to principals directly for a better separation and future
>>>migrations.
>>
>>IMO, the granting of permissions to roles should be hidden from
>>users. I would treat this as software configuration.  That's
>>why I moved this UI to ++etc++site a few months ago.
>>
>>IMO, users should not be allowed to grant permissions to users.
>>Disallowing this would:
>>
>>- Allow us to change role-permission assignments centrally, and
>>
>>- would simplify and allow a much better granting interface.
>>
>>An even better alternative, if someone was so inspired, would
>>be for someone to make a new security policy from the
>>current one by changing the word "role" to something else
>>(e.g. "privilege") throughout. (There would probably be some
>>other minor word changes.) This would be a purely mechanical
>>change -- still a fair bit of work.  We could make this new
>>security policy  the default.
> 
> 
> You mean the ZopeSecurityPolicy in zope.app.securitypolicy?

I mean make a new package by copying zope.app.securitypolicy.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org