[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 )
> >
>