[Zope3-dev] Permission granularity/permission groups

[Peter Simmons]

Hi,

If that's a proposal then +1 from me :-)

Cheers,
Pete

Jim Fulton wrote:

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