[Zope-dev] LoginManager patch considered harmful

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote:
> >
> >The new security machinery actually provides a different way to solve
> >this problem.  Since we now have an execution stack, we can limit that
> >stack, causing an exception to be thrown rather than letting it
> >overflow the C stack.  It would actually be more reliable than the
> >current mechanism, which depends on DTML namespaces.
> 
> That would probably be a good idea, independent of LoginManager et al.

Well, guess what... Jim's ahead of both of us.  Not only is the stack
size limited, but the limit is easily configured through an environment
variable.  I never give this guy enough credit. :-)  See
lib/python/AccessControl/SecurityManager.py, especially addContext().

> >If the LoginManager is created by the superuser and is used as the root
> >authenticator, it stays unowned, so the ownership problem should not
> >occur.  If that is not the current behavior then it needs to be
> >corrected.
> 
> That is not the current behavior, unless _owned=UnownableOwner is placed in
> the class.

It looks like Brian decided, for the latest beta, to make ownership
forgiving in the presence of an _owner class attribute.  This should
solve the problem for Generic User Source.  Generic User Folder is
going to need the _owner attribute.

> >If untrusted users are allowed to add LoginManagers, the methods called
> >to get ownership information should be owned by them.  This is to avoid
> >the server-side trojan horse.
> 
> Understood.  I'll try to keep that use case in mind.  Keep in mind,
> however, that being able to create a LoginManager is a pretty risky
> business in a portalish environment - you could potentially get access to
> somebody's password, since after all you will control an actual login
> screen!  (Note however, that someone can create a phony login screen in
> DTML and bypass the entire Zope security model with a little "social
> engineering" anyway.)

I've thought of that as well.  Perhaps we'll have to accept that the
new model just doesn't lend itself to the area of configurable user
databases.

> Also note that it is not necessary to give a user access to the full power
> of LoginManager.  One could give them rights only to add a small subset of
> the available UserSources and LoginMethods.  It would probably be a bad
> idea to give them the ability to add a GenericUserSource, which is where
> most of the potential for mayhem lies.  Better to give them some sort of
> PersistentUserSource, with no ability to do much.
> 
> >Now, the problem still remains that ownership information cannot be
> >retrieved if the method that gets ownership is in ZODB, is owned by a
> >user defined in that user folder, and has to call another method.  Note
> >that this also applies to Generic User Folder.
> 
> Yep.  The problem is that the superuser *can't* create those methods in the
> root folder, so there's no place to bottom out the recursion at present.
>
> >With the correction in the execution stack, instead of killing Zope, an
> >attempt to authenticate that way will result in a controlled stack
> >overflow.  Unless you can come up with another option, we can either
> >break the security model or slightly reduce the capabilities of
> >LoginManager.
> >
> >What would you do if you were in my position?
> 
> Well, I'm hoping you'll take a look at my Collector suggestion for a new
> Zope feature.  :)  Specifically, extending the "access" file to allow other
> "top-level" users to exist besides the superuser, who have roles defined in
> the file.  There are many ways this would be useful, not the least of which
> is to break the "you need to do that at the next level up" problem.
> (Others include a simplified process for getting your Zope site set up,
> since you then don't have to login as superuser and add a user folder, then
> log back in as somebody else.)
>
> If this were done, we could easily go to letting LoginManager objects be
> owned, since there'd always be a place "above" the LoginManager for the
> owner user to reside.

Hmm... this sounds like a good idea, but now that the ownership problem
has been resolved in a way I didn't expect, the issue that motivated
your idea is gone.

Shane