[Zope-dev] LoginManager patch considered harmful

[Phillip J. Eby]

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.


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


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

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.