"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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
