[Zope-dev] FW: [Zope-dev] pam authentication support with PyPam

Alexander Staubo alex@mop.no
Wed, 20 Oct 1999 01:48:43 +0200


Hey, how did this end up on the Zope mailing list? (eeek!)

> -----Original Message-----
> From: Alexander Staubo 
> Sent: 18. oktober 1999 18:44
> To: Zope Mailing List (E-mail); 'Michel Pelletier'
> Subject: RE: [Zope-dev] pam authentication support with PyPam
> 
> 
> There are two aspedcts of the current security subsystem that bug me.
> 
> The first is the fact that only user folders are accumulative 
> only at folder boundaries. You cannot create one UserFolder 
> and one NTUserFolder at the same level and have them co-opt 
> the user authentication responsibility.
> 
> The second, more serious gripe is with the security 
> permission model. Look at NT 4.0 and the security UI that 
> comes with SP4/SP5's Security Configuration Manager for a 
> good example (installing it will upgrade NT's security 
> dialogs with a new UI).
> 
> While Zope permits acquired, accumulative access definitions 
> specified across _all_ roles for each permission, this is too 
> coarse and leads to huge sysadmin headaches (I know -- I've 
> been there, and I'm still there).
> 
> We need fine-grained, per-role permissions that let us 
> specify whether a role acquired the permissions of the 
> parent, or whether it allows or denies the permission. 
> Instead of the matrix we have today (below, "[X]" denotes a checkbox):
> 
> Acquire    Permission                     Anonymous   Manager   Owner
> [X]        Access contents information    [X]         [X]       [X]
> [X]        View                           [X]         [X]       [X]
> [X]        View management screens        [X]         [X]       [X]
> 
> ...we ought to have something like this (here, "[...][]" 
> denotes a combo box):
> 
> Permission                      Anonymous   Manager     Owner
> Access contents information     [Acquire][] [Deny   ][] [Allow  ][]
> View                            [       ][] [       ][] [       ][]
> View management screens         [       ][] [       ][] [       ][]
> 
> Each combo box would be set to either "Acquire", "Allow", or "Deny".
> 
> "Acquire" has the role acquire the permission setting of the 
> acquisition parent. "Allow" specifically gives the permission 
> to that role. "Deny", of course, explicitly denies the 
> permission to the role.
> 
> I shouldn't need to point this out as it should be paintfully 
> obvious to anyone who has used Zope's permission settings, 
> but the problem is that a role's permission setting is either 
> allow/deny, but the acquisition switch applies to all the 
> roles. One you un-check the "Acquire permissions..." 
> checkbox, you must explicitly define the permissions for each 
> role, independent of whether the role is relevant. In a 
> small, flat, and/or simple ZODB this system is usually 
> endurable, but in a real-world object hierarchy where roles 
> must be delegated carefully, it doesn't work.
> 
> The problem is exacerbated by the fact that Zope has no 
> provision for summarizing the security permissions in effect 
> throughout the site, or batch-applying security settings. If 
> subfolder Foo's permission settings deviate from that of a 
> parent, I can't know unless I go to the folder and look at 
> the security tab. One folder is okay; if you have a hundred 
> of those, it's a tad more serious.
> 
> -- 
> Alexander Staubo             http://www.mop.no/~alex/
> "Give me an underground laboratory, half a dozen atom smashers and
> a beautiful girl in a diaphanous veil waiting to be turned into a
> chimpanzee, and I care not who writes the nation's laws."
> --S. J. Perelman
> 
> > -----Original Message-----
> > From: Michel Pelletier [mailto:michel@digicool.com]
> > Sent: 18. oktober 1999 16:13
> > To: 'Will Fife'; Oleg Broytmann
> > Cc: zope-dev@zope.org
> > Subject: RE: [Zope-dev] pam authentication support with PyPam
> > 
> > 
> > Regardless of whether or not Zope has a PAM folder (which I 
> think is a
> > good idea) we need to discuss an upcomming problem with Zope user
> > authentication: the proliferation of user folders.
> > 
> > The problem is there are now quite a few user folders that all kinda
> > look the same, smell the same, and share a good bit of 
> code.  This is
> > very brittle.  The 'backends' should be abstracted away from the
> > 'frontend' and we should return to the original state of 
> > grace, one type
> > of user folder.
> > 
> > At the moment if we were to change an aspect of Zope 
> > authentication that
> > would break existing user folders, we would have to go and fix every
> > single one, the orpaned ones without maintainers (like 
> > etcUserFolder, my
> > personal orphan) would simply remain broken until someone got 
> > frustrated
> > enough to fix them.  This is a pretty bad state of affairs.
> > 
> > So lets fire up a discussion on what kind of model we could 
> > impliment to
> > have a generic user folder with pluggable backends (one of 
> which could
> > be PAM).  It might even be a good idea to look *at* PAM for 
> > some ideas,
> > anyone here a PAM expert?
> > 
> > Hmm.. it might also be nice to take Membership and the ZPT into
> > consideration here, like support for extensable user objects (if the
> > 'backend' supports it) etc.
> > 
> > -Michel
> > 
> > _______________________________________________
> > Zope-Dev maillist  -  Zope-Dev@zope.org
> > http://www.zope.org/mailman/listinfo/zope-dev
> > 
> > (Related lists - please, no cross posts or HTML encoding!
> > 
> > To receive general Zope announcements, see:
> > http://www.zope.org/mailman/listinfo/zope-announce
> > 
> > For non-developer, user-level issues, 
> > zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
> > 
>