RE: Superuser ownership (was "Adding LoginManager at the root")
At 03:13 PM 5/16/00 -0400, Tres Seaver wrote:
Nope, because objects owned by 'nobody' would be almost useless -- the intersection of nobody's permissions with any other users' is an empty set.
After reviewing the 2.2 code today, Ty and I have found some problems with the current terminology, API, and implementation of the new security system. Here is the short summary of what we found/propose: 1. The "owner" concept is extremely confusing to talk about, explain, etc. We propose a terminology change to "responsible user", and to "taking responsibility" for an object instead of "taking ownership" of an object. We further propose that all API's and attributes be renamed to reflect this terminology rather than "owner". (One benefit is that "take responsibility" sounds like something you'd want to be wary of, while "take ownership" sounds too much like something *good*.) 2. The current implementation/usage of "manage_fixupOwnership" seems broken to us, in that moving, renaming, and importing objects causes the current user to silently take responsibility for an entire object subtree. We think this is unequivocally broken with respect to renaming, and there are common use cases for which the current moving and importing behavior would have to be considered broken. We propose that only copying and adding should involve an implicit "take responsibility" action. 3. The ability of the superuser to be responsible for objects should be acquirable in some fashion, so that objects such as LoginManager and GenericUserSource (which require objects to be created inside them for bootstrapping) can permit "standard" Zope objects to be created within them by the superuser. Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership. 4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw that could seriously impact performance when used with user objects which are not part of the ZODB. Specifically, ZSP asks executing objects for their "owner" objects, which causes a getUserById() hit, which can potentially cause external database lookups... for every single DTML name lookup! Further complicating things is that GenericUserSource and GenericUserFolder may call back to this very same security lookup in order to determine access to an SQLMethod or LDAPMethod needed to look up the user! We propose a refinement to the addContext/removeContext that allows the "responsible user" to be placed on the context stack, rather than having it looked up later by the security policy. This could still have a significant performance impact when calling DTML methods in an "in" loop, but would still be better than the current situation in all but pathological cases.
"Phillip J. Eby" wrote:
(snip)
After reviewing the 2.2 code today, Ty and I have found some problems with the current terminology, API, and implementation of the new security system. Here is the short summary of what we found/propose:
1. The "owner" concept is extremely confusing to talk about, explain, etc. We propose a terminology change to "responsible user", and to "taking responsibility" for an object instead of "taking ownership" of an object. We further propose that all API's and attributes be renamed to reflect this terminology rather than "owner". (One benefit is that "take responsibility" sounds like something you'd want to be wary of, while "take ownership" sounds too much like something *good*.)
I'm not going to play in a naming argument. I'll leave that to Brian and others. I'd be happy to call it penguin. (Dang, that names taken ....)
2. The current implementation/usage of "manage_fixupOwnership" seems broken to us, in that moving, renaming, and importing objects causes the current user to silently take responsibility for an entire object subtree. We think this is unequivocally broken with respect to renaming, and there are common use cases for which the current moving and importing behavior would have to be considered broken. We propose that only copying and adding should involve an implicit "take responsibility" action.
I can agree wrt naming. I don't agree wrt import. Import is equivalent to copy. Moving is close enough, IMO.
3. The ability of the superuser to be responsible for objects should be acquirable in some fashion,
superuser can never be responsible, however, the same effect is had by making an object unowned.
so that objects such as LoginManager and GenericUserSource (which require objects to be created inside them for bootstrapping) can permit "standard" Zope objects to be created within them by the superuser.
Why *must* this be done by the superuser?
Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership.
If you need to assure that all objects under some object are unowned, then that can be arranged. (Hint, grep for "UnownableOwner" in the sources.)
4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw that could seriously impact performance when used with user objects which are not part of the ZODB. Specifically, ZSP asks executing objects for their "owner" objects, which causes a getUserById() hit, which can potentially cause external database lookups... for every single DTML name lookup! Further complicating things is that GenericUserSource and GenericUserFolder may call back to this very same security lookup in order to determine access to an SQLMethod or LDAPMethod needed to look up the user! We propose a refinement to the addContext/removeContext that allows the "responsible user" to be placed on the context stack, rather than having it looked up later by the security policy. This could still have a significant performance impact when calling DTML methods in an "in" loop, but would still be better than the current situation in all but pathological cases.
I can live with this. Could you make a proposal in the Wiki? Alternatively (or in addition), we could automagically cache this information in the context. Note that part of the rational of the SecurityPolicy api was to provide *you* the hooks you needed to choose a different policy. For example, the API would allow you to turn off the ownership checks for an entire site or for specific executable objects. The API turned out to be a huge improvement for other reasons. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 05:12 PM 5/16/00 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
2. The current implementation/usage of "manage_fixupOwnership" seems broken to us, in that moving, renaming, and importing objects causes the current user to silently take responsibility for an entire object subtree. We think this is unequivocally broken with respect to renaming, and there are common use cases for which the current moving and importing behavior would have to be considered broken. We propose that only copying and adding should involve an implicit "take responsibility" action.
I can agree wrt naming. I don't agree wrt import. Import is equivalent to copy.
Consider the situation of someone with "development" and "production" sites, exporting from one and importing to the other. Import is now "lossy" with respect to responsibility.
Moving is close enough, IMO.
If I make a copy of something on my desk, I expect it to not be the original, so although I would expect it to work like the original, I could understand that I would be responsible for the copy (since I made it). But if I move something on my desk to the other side, I don't expect it to suddenly stop working, unless there is something about where it was that made it work. In that case, I would assume that moving it back would fix it. But moving it back doesn't fix it, because the objects were actually changed. When all you did was move them, changing objects irreversibly seems just plain *wrong* to me. I just moved the document: I didn't even *read* it, let alone modify it or sign off on it!
3. The ability of the superuser to be responsible for objects should be acquirable in some fashion,
superuser can never be responsible, however, the same effect is had by making an object unowned.
Hm. Perhaps in the proposed terminology, an "unowned" object could be called an "irresponsible" object, which seems to have appropriate connotations. :)
so that objects such as LoginManager and GenericUserSource (which require objects to be created inside them for bootstrapping) can permit "standard" Zope objects to be created within them by the superuser.
Why *must* this be done by the superuser?
Because as far as I can tell, until it's done, superuser and nobody are the only users that exist to do it, if you want a GUF, GUS, or similar object as your root acl_users. You can't even make another user in a temporary user folder, because if you copy the acl_users as superuser, you aren't allowed because it would give the superuser responsibility. And if you delete the root acl_users so that you can then have the "manager" user do the copy, the manager can no longer log in, because he doesn't exist any more! (Incidentally, this is another use case which suggests that moves causing a responsibility change is wrong, since if they didn't do this, the superuser could move acl_users to the root, assuming it was movable.)
Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership.
If you need to assure that all objects under some object are unowned, then that can be arranged. (Hint, grep for "UnownableOwner" in the sources.)
We skimmed alot of the UnownableOwner stuff because it made our brains ache. :) (All the darting back and forth between UnownableOwner vs. None was confusing.) Upon re-reading, it seems to me that if one were to set _owner = UnownableOwner in a class, it would ensure that anything contained underneath that location would be unable to have ownership assigned to it. Is that correct?
4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw that could seriously impact performance when used with user objects which are not part of the ZODB. Specifically, ZSP asks executing objects for their "owner" objects, which causes a getUserById() hit, which can potentially cause external database lookups... for every single DTML name lookup! Further complicating things is that GenericUserSource and GenericUserFolder may call back to this very same security lookup in order to determine access to an SQLMethod or LDAPMethod needed to look up the user! We propose a refinement to the addContext/removeContext that allows the "responsible user" to be placed on the context stack, rather than having it looked up later by the security policy. This could still have a significant performance impact when calling DTML methods in an "in" loop, but would still be better than the current situation in all but pathological cases.
I can live with this. Could you make a proposal in the Wiki? Alternatively (or in addition), we could automagically cache this information in the context.
For the specific situation identified, caching in the context would address the problem. It still wouldn't fix loops where a DTML method is called repeatedly as part of a larger page, because the method would be added and removed from the context stack repeatedly, and thus lose the cached user information (unless perhaps it's done with a _v_ attribute on the executable itself). I'm also thinking that ZPatterns.Rack probably needs a per-transaction cache (i.e. cleared between transactions) so that repeated lookups like this within a single transaction can be generally avoided.
Note that part of the rational of the SecurityPolicy api was to provide *you* the hooks you needed to choose a different policy. For example, the API would allow you to turn off the ownership checks for an entire site or for specific executable objects. The API turned out to be a huge improvement for other reasons.
I can see that, and I do like the idea. It's only the issues related to ownership/responsibility that give Ty and I the creeps. That part really has no direct relationship to the SecurityManager/SecurityPolicy type stuff, which could probably be usefully packaged with ZPublisher as a standalone system.
"Phillip J. Eby" wrote:
I can agree wrt naming. I don't agree wrt import. Import is equivalent to copy.
Consider the situation of someone with "development" and "production" sites, exporting from one and importing to the other. Import is now "lossy" with respect to responsibility.
I'm with you on this one - it's very common for us to have two servers, and to move stuff between them using export/import in order to keep them in sync. If import changes the ownership, this makes it virtually impossible to do without resorting to moving the whole Data.fs. The same goes for moving - lets say I'm rearranging the site and have to move the Portal object. If the managing user that moved the Portal becomes owner of all these objects, the whole Portal has been screwed up, since Portal members no longer own their own documents. -- Itamar S.T. itamar@maxnm.com
"Phillip J. Eby" wrote:
At 05:12 PM 5/16/00 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
2. The current implementation/usage of "manage_fixupOwnership" seems broken to us, in that moving, renaming, and importing objects causes the current user to silently take responsibility
I should have remarked that the user is explicitly doing something. There isn't really anything solient about it.
for an entire object subtree. We
think this is unequivocally broken with respect to renaming, and there are common use cases for which the current moving and importing behavior would have to be considered broken. We propose that only copying and adding should involve an implicit "take responsibility" action.
I can agree wrt naming. I don't agree wrt import. Import is equivalent to copy.
Consider the situation of someone with "development" and "production" sites, exporting from one and importing to the other. Import is now "lossy" with respect to responsibility.
No, It's gainy, uh, or maybe switchy. :)
Moving is close enough, IMO.
If I make a copy of something on my desk, I expect it to not be the original, so although I would expect it to work like the original, I could understand that I would be responsible for the copy (since I made it). But if I move something on my desk to the other side, I don't expect it to suddenly stop working, unless there is something about where it was that made it work. In that case, I would assume that moving it back would fix it. But moving it back doesn't fix it, because the objects were actually changed. When all you did was move them, changing objects irreversibly seems just plain *wrong* to me. I just moved the document: I didn't even *read* it, let alone modify it or sign off on it!
You are slowly swaying me on this ..... I'll let Brian figure out if there is a consensus on this.
3. The ability of the superuser to be responsible for objects should be acquirable in some fashion,
superuser can never be responsible, however, the same effect is had by making an object unowned.
Hm. Perhaps in the proposed terminology, an "unowned" object could be called an "irresponsible" object, which seems to have appropriate connotations. :)
:)
so that objects such as LoginManager and GenericUserSource (which require objects to be created inside them for bootstrapping) can permit "standard" Zope objects to be created within them by the superuser.
Why *must* this be done by the superuser?
Because as far as I can tell, until it's done, superuser and nobody are the only users that exist to do it, if you want a GUF, GUS, or similar object as your root acl_users. You can't even make another user in a temporary user folder, because if you copy the acl_users as superuser, you aren't allowed because it would give the superuser responsibility. And if you delete the root acl_users so that you can then have the "manager" user do the copy, the manager can no longer log in, because he doesn't exist any more! (Incidentally, this is another use case which suggests that moves causing a responsibility change is wrong, since if they didn't do this, the superuser could move acl_users to the root, assuming it was movable.)
Hm. Interesting point.
Currently, this would have to be done by overriding _setObject in these classes such that it doesn't call manage_fixupOwnership.
If you need to assure that all objects under some object are unowned, then that can be arranged. (Hint, grep for "UnownableOwner" in the sources.)
We skimmed alot of the UnownableOwner stuff because it made our brains ache. :) (All the darting back and forth between UnownableOwner vs. None was confusing.) Upon re-reading, it seems to me that if one were to set _owner = UnownableOwner in a class, it would ensure that anything contained underneath that location would be unable to have ownership assigned to it. Is that correct?
Right, at least without low-level intervention.
4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw that could seriously impact performance when used with user objects which are not part of the ZODB. Specifically, ZSP asks executing objects for their "owner" objects, which causes a getUserById() hit, which can potentially cause external database lookups... for every single DTML name lookup! Further complicating things is that GenericUserSource and GenericUserFolder may call back to this very same security lookup in order to determine access to an SQLMethod or LDAPMethod needed to look up the user! We propose a refinement to the addContext/removeContext that allows the "responsible user" to be placed on the context stack, rather than having it looked up later by the security policy. This could still have a significant performance impact when calling DTML methods in an "in" loop, but would still be better than the current situation in all but pathological cases.
I can live with this. Could you make a proposal in the Wiki? Alternatively (or in addition), we could automagically cache this information in the context.
For the specific situation identified, caching in the context would address the problem. It still wouldn't fix loops where a DTML method is called repeatedly as part of a larger page, because the method would be added and removed from the context stack repeatedly, and thus lose the cached user information (unless perhaps it's done with a _v_ attribute on the executable itself).
There is a terminology problem here. The SecurityPolicies API, http://www.zope.org/Members/michel/Projects/Interfaces/SecurityPolicies, uses the term context for two concepts. Context is both an overall context that is passed to policy objects and the incremental context added by an executable. I was suggesting that we cache owners in the per-request not per-executable context. (lib/python/AccessControl/ SecurityManagement.SecurityContext). (snip)
Note that part of the rational of the SecurityPolicy api was to provide *you* the hooks you needed to choose a different policy. For example, the API would allow you to turn off the ownership checks for an entire site or for specific executable objects. The API turned out to be a huge improvement for other reasons.
I can see that, and I do like the idea. It's only the issues related to ownership/responsibility that give Ty and I the creeps. That part really has no direct relationship to the SecurityManager/SecurityPolicy type stuff, which could probably be usefully packaged with ZPublisher as a standalone system.
That's the whole point. The SecurityPolicies API is security-policy agnostic. OTOH, Zope has it's *own* security policy, which you can choose not to use if you wish. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Is there any clear way for stuff which used to work under the old api to be migrated to 2.2? I'm presently unable to create tinytables as super user (presumably because they lack the relevant attributes). I used to be able to access them anonymously, but am unable to under 2.2. For the non-expert what would we have to do to get up to speed on what needs to be hacked to get these things to go? It's not clear whether I need to hack the implementation of tinytable or if the objects in the fs or .zexp are bad or all are outdated. There must be a lot of older databases which will encounter this and similar problems. -- Robin Becker
Robin Becker wrote: [stuff about 2.2] You can't create any objects except User Objects as the superuser. Create a manager, re-login as that manager and then add yoru objects. Can't speak for TinyTables but make sure the Anonymous role has the 'access TinyTables contents' permission. A lot of people get bitten by this when installign Squishdot 'cos Anonymous does not have this permission by default... cheers, Chris
In article <39290348.DCCD27F@nipltd.com>, Chris Withers <chrisw@nipltd.com> writes
Robin Becker wrote: [stuff about 2.2]
You can't create any objects except User Objects as the superuser. Create a manager, re-login as that manager and then add yoru objects.
Can't speak for TinyTables but make sure the Anonymous role has the 'access TinyTables contents' permission. A lot of people get bitten by this when installign Squishdot 'cos Anonymous does not have this permission by default...
cheers,
Chris
... What kind of idiotic permissions model is this where God cannot create anything? What is the function of the super user if not to manage? Seems to be specially designed for bureaucrats, lawyers and politicians. I have already added the query tinytables back to anonymous. This still doesn't answer my question. How do I get a zope 2 database to work under 2.2? Do I have to try and reread all the non-existent documentation? What parts of the awful API have been further corrupted? The Zope noospheric habitat seems ripe for take-over by rationalists :) -- Robin Becker
Robin Becker wrote:
What kind of idiotic permissions model is this where God cannot create anything? What is the function of the super user if not to manage?
The super user is not god, that was seen to be an insecure thing. The super user is a facilitator for creating god... ;-)
Seems to be specially designed for bureaucrats, lawyers and politicians.
Actually, it's more to thwart little script kiddie hackers...
I have already added the query tinytables back to anonymous. This still doesn't answer my question. How do I get a zope 2 database to work under 2.2?
Might help if you said what problems you were experiencing... Basic steps I would try are either: -just bring the data.fs from you 2.1 install and replace the blank one in the 2.2 with a *copy* of it.. -export stuff, as required, from you old install and move it into your new one...
Do I have to try and reread all the non-existent documentation?
touche... ...maybe when you solve your problem you could write some documentation on how to solve similar ones? see zdp.zope.org
What parts of the awful API have been further corrupted? The Zope noospheric habitat seems ripe for take-over by rationalists :)
Well, you don't have to use Zope... cheers, Chris
In article <39291077.2FF4D37E@nipltd.com>, Chris Withers <chrisw@nipltd.com> writes ...
Might help if you said what problems you were experiencing...
... I already did. I cannot use the preexisting database tinytables. Following your suggestion I can create God, and then having logged in as God I can actually create tiny tables. What steps should I try to allow my currently unowned documents/tinytables to be made accessible. When I press the change ownership button I get a help browser with an error message in the content frame. Should I just import everything as God and hope that improves things? -- Robin Becker
Robin Becker wrote:
In article <39291077.2FF4D37E@nipltd.com>, Chris Withers <chrisw@nipltd.com> writes ...
Might help if you said what problems you were experiencing...
... I already did. I cannot use the preexisting database tinytables. Following your suggestion I can create God, and then having logged in as God I can actually create tiny tables.
What steps should I try to allow my currently unowned documents/tinytables to be made accessible. When I press the change ownership button I get a help browser with an error message in the content frame.
If I am not mistaken, the "migrating to Zope 2.2" page gives an example method to convert objects to the new security model. http://www.zope.org/Products/Zope/2.2.0a1/upgrading_to_220
Robin Becker wrote:
What steps should I try to allow my currently unowned documents/tinytables to be made accessible. When I press the change ownership button I get a help browser with an error message in the content frame.
That sounds like a 2.2 bug to me... oh well... it is Alpha so fair enough. Can you mail the whole error message (especially the traceback) to the list please :-)
Should I just import everything as God and hope that improves things?
Might help... Could you import stuff as the superuser? ('cos I think you shouldn't be able to...) cheers, Chris
In article <39291BF2.652580CA@nipltd.com>, Chris Withers <chrisw@nipltd.com> writes
Robin Becker wrote:
What steps should I try to allow my currently unowned documents/tinytables to be made accessible. When I press the change ownership button I get a help browser with an error message in the content frame.
That sounds like a 2.2 bug to me... oh well... it is Alpha so fair enough. Can you mail the whole error message (especially the traceback) to the list please :-) perhaps the superuser should be renamed to initial user or something. OK here it is; this when I press the take ownership button on my Folder at / manage ownership panel.
Zope Error Zope has encountered an error while publishing this resource. Debugging Notice Zope has encountered a problem publishing your object. Cannot locate object at: http://jessikat/Control_Panel/Products/OFSP/Help/Ownership.d tml Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File C:\Python\devel\Zope\lib\python\ZPublisher\Publish.py, line 224, in publish_module File C:\Python\devel\Zope\lib\python\ZPublisher\Publish.py, line 189, in publish File C:\Python\devel\Zope\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook (Object: Help) File C:\Python\devel\Zope\lib\python\ZPublisher\Publish.py, line 161, in publish File C:\Python\devel\Zope\lib\python\ZPublisher\BaseRequest.py, line 350, in traverse File C:\Python\devel\Zope\lib\python\ZPublisher\HTTPResponse.py, line 530, in debugError NotFound: (see above)
Should I just import everything as God and hope that improves things?
Might help...
Could you import stuff as the superuser? ('cos I think you shouldn't be able to...)
cheers,
Chris
-- Robin Becker
Robin Becker wrote:
What kind of idiotic permissions model is this where God cannot create anything? What is the function of the super user if not to manage?
Seems to be specially designed for bureaucrats, lawyers and politicians.
I feel like this specifically needed to be addressed. This change in the ability of superuser stems directly from a security issue common to all through-the-web interfaces: http://www.zope.org/Members/jim/ZopeSecurity/TrojanIssueOverview The superuser cannot create objects, because any object that was owned by superuser would have permission to do whatever it pleased. Hope that's a bit more explanatory, ~ethan mindlace fremen digicool & imeme
On Mon, May 22, 2000 at 10:23:38AM -0600, mindlace wrote:
Robin Becker wrote:
What kind of idiotic permissions model is this where God cannot create anything? What is the function of the super user if not to manage? Seems to be specially designed for bureaucrats, lawyers and politicians.
I feel like this specifically needed to be addressed. This change in the ability of superuser stems directly from a security issue common to all through-the-web interfaces: http://www.zope.org/Members/jim/ZopeSecurity/TrojanIssueOverview The superuser cannot create objects, because any object that was owned by superuser would have permission to do whatever it pleased.
Yes, but if people _want_ to create superuser objects that can do anything they should be permitted to. As long as the superuser doesn't make really stupid objects they shouldn't get bitten. The problem is that the new security model should have more handholding to go along with it. Perhaps the superuser should be changed to the name "usermanager" or "permissionsmanager" or something like that and a default superuser with the behaviour every actually expects the superuser to have be created as well. As it stands now you need _two_ "superuser" type users, so they should both be created automatically instead of having to create one of them manually afterwards. Also I still maintain that, as well as the "Take Permissions" permission that a NONE permissioned method should be available for ownership transfer, that you can "offer" an object to someone and they can later on "accept" it when they log in. (Like the moderation concept in Squishdot) This is needed for cases where a site manager has say a hundred projects going on under their Zope server. When one of the projects changes project leader and leaves they have to transfer ownership to their successor, but they _can't_ because their successor is _less_ authorised than they are and can't "take permissions". In this case they currently have to petition the person running the site to change all of the permissions for their project over. This is a waste of everyone's time and completely unecessary. With a challenge/response transfer of objects you have complete security maintained (especially if you allow the person accepting the ownership to preview the object prior to their decision to accept it.) It's more work to set up this system because nothing in core Zope uses this type of messaging once people login, but it's a much broader and usable means for ownership transfer without losing any security.
Hope that's a bit more explanatory, ~ethan mindlace fremen digicool & imeme
-- Evan ~ThunderFoot~ Gibson ~ nihil mutatem, omni deletum ~ It doesn't count as intimacy until somebody starts crying.
participants (8)
-
Bill Anderson -
Chris Withers -
Evan Gibson -
Itamar Shtull-Trauring -
Jim Fulton -
mindlace -
Phillip J. Eby -
Robin Becker