[Zope3-dev] Permission granularity/permission groups

[Roger Ineichen]

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?


Regards
Roger Ineichen

Projekt01 GmbH
www.projekt01.ch
_____________________________
END OF MESSAGE  

> -----Original Message-----
> 

> 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
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>