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.