Newbie Question (Content Manager Tutorial)
Hi All, I decided today was learn Zope Day. I expect to be pounding the list with some newbie questions. I installed Zope 2.2.0 on a Win 98 machine. Seems to work fine. I dloaded the Content Manager Guide and started working through the tutorial. Went to create a folder as instructed. Id: News Title: The ZAcme News X Create public interface X Create user folder Below is what I got. What am I doing wrong? Thanks All Mark Pappas Zope Error Zope has encountered an error while publishing this resource. Error Type: SuperCannotOwn Error Value: Objects cannot be owned by the superuser ---------------------------------------------------------------------------- ---- 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:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 222, in publish_module File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 187, in publish File C:\Program Files\WebSite\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 171, in publish File C:\Program Files\WebSite\lib\python\ZPublisher\mapply.py, line 160, in mapply (Object: manage_addFolder) File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 112, in call_object (Object: manage_addFolder) File C:\Program Files\WebSite\lib\python\OFS\Folder.py, line 116, in manage_addFolder File C:\Program Files\WebSite\lib\python\OFS\ObjectManager.py, line 249, in _setObject (Object: ApplicationDefaultPermissions) File C:\Program Files\WebSite\lib\python\AccessControl\Owned.py, line 271, in manage_fixupOwnershipAfterAdd (Object: ElementWithAttributes) SuperCannotOwn: (see above)
Darn. Those docs are a little (.... ok, a lot...) out of date. They're still useful, but they don't cover a few things. With the advent of Zope 2.2, the first thing you need to do is to create a management user. You cannot use the 'superuser' to manage content. I know this is a little unfamiliar, but, for now, just suspend disbelief and create another user with the 'Manager' role (by visiting the acl_users User Folder and adding a user). Then quit the browser, and log in as the user you created. You'll then be able to follow the cmg. On Sat, 19 Aug 2000, Mark A. Pappas wrote:
Hi All, I decided today was learn Zope Day. I expect to be pounding the list with some newbie questions.
I installed Zope 2.2.0 on a Win 98 machine. Seems to work fine. I dloaded the Content Manager Guide and started working through the tutorial. Went to create a folder as instructed.
Id: News Title: The ZAcme News
X Create public interface X Create user folder
Below is what I got. What am I doing wrong? Thanks All Mark Pappas
Zope Error Zope has encountered an error while publishing this resource.
Error Type: SuperCannotOwn Error Value: Objects cannot be owned by the superuser
---------------------------------------------------------------------------- ----
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:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 222, in publish_module File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 187, in publish File C:\Program Files\WebSite\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 171, in publish File C:\Program Files\WebSite\lib\python\ZPublisher\mapply.py, line 160, in mapply (Object: manage_addFolder) File C:\Program Files\WebSite\lib\python\ZPublisher\Publish.py, line 112, in call_object (Object: manage_addFolder) File C:\Program Files\WebSite\lib\python\OFS\Folder.py, line 116, in manage_addFolder File C:\Program Files\WebSite\lib\python\OFS\ObjectManager.py, line 249, in _setObject (Object: ApplicationDefaultPermissions) File C:\Program Files\WebSite\lib\python\AccessControl\Owned.py, line 271, in manage_fixupOwnershipAfterAdd (Object: ElementWithAttributes) SuperCannotOwn: (see above)
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris McDonough wrote:
With the advent of Zope 2.2, the first thing you need to do is to create a management user. You cannot use the 'superuser' to manage content.
Can anyone remind me why? T0he problems it's caused, particularly with broswers caching basic auth info, seem to be pretty nasty for newbies (and a few oldbies ;-) cheers, Chris
See (sneak peek) http://www.zope.org/Members/mcdonc/PDG/6-1-Security.stx, section named "The Superuser". I hope to have this chapter really finished this weekend. On Sat, 19 Aug 2000, Chris Withers wrote:
Chris McDonough wrote:
With the advent of Zope 2.2, the first thing you need to do is to create a management user. You cannot use the 'superuser' to manage content.
Can anyone remind me why?
T0he problems it's caused, particularly with broswers caching basic auth info, seem to be pretty nasty for newbies (and a few oldbies ;-)
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris McDonough wrote:
See (sneak peek) http://www.zope.org/Members/mcdonc/PDG/6-1-Security.stx, section named "The Superuser".
No offence meant, but it doesn't do a very good job of explaining _why_ the superuser can't own anything. Come to thing of it, is there a concise description anywhere of what the new rules are WRT to ownership, the logged in user and how 'code' of all the various types is executed? cheers, Chris
See (sneak peek) http://www.zope.org/Members/mcdonc/PDG/6-1-Security.stx, section named "The Superuser".
No offence meant, but it doesn't do a very good job of explaining _why_ the superuser can't own anything.
Well, I think the real problem is that the account that you use to "bootstrap" Zope is named "superuser". If it was named something else like "bootstrapuser" or "fixupuser" or something, I doubt you'd wonder why it couldn't own anything.
Come to thing of it, is there a concise description anywhere of what the new rules are WRT to ownership, the logged in user and how 'code' of all the various types is executed?
What isn't covered in that document that you'd like to know?
Chris McDonough wrote:
See (sneak peek) http://www.zope.org/Members/mcdonc/PDG/6-1-Security.stx, section named "The Superuser".
No offence meant, but it doesn't do a very good job of explaining _why_ the superuser can't own anything.
Well, I think the real problem is that the account that you use to "bootstrap" Zope is named "superuser". If it was named something else like "bootstrapuser" or "fixupuser" or something, I doubt you'd wonder why it couldn't own anything.
Well, okay, let me rephrase the question: Why is it bad for the bootstrap user to own anything? It used to be considered okay before Zope 2.2, so was has been changed/discovered that makes this now such a bad idea that despite loads of newbie pain and confusion, it's still worth while/necessary?
Come to thing of it, is there a concise description anywhere of what the new rules are WRT to ownership, the logged in user and how 'code' of all the various types is executed?
What isn't covered in that document that you'd like to know?
Urm, again, no offence ('cos I think the book is aimed at a different audience) but the keyword for me was 'concise'. I did have a look at the document above, but didn't read it 'cos it looked about 10 pages long :-( I'm looking for something closer to 10 _lines_ long, but that may not be possible ;-) cheers, Chris
On Mon, 4 Sep 2000, Chris Withers wrote:
Well, I think the real problem is that the account that you use to "bootstrap" Zope is named "superuser". If it was named something else like "bootstrapuser" or "fixupuser" or something, I doubt you'd wonder why it couldn't own anything.
Well, okay, let me rephrase the question: Why is it bad for the bootstrap user to own anything? It used to be considered okay before Zope 2.2, so was has been changed/discovered that makes this now such a bad idea that despite loads of newbie pain and confusion, it's still worth while/necessary?
I've got to say I agree with you here. I'm still not 100% sure why the superuser or bootstrap user can't own anything. The argument for protecting the user against himself by making this so is something I had a rough time rationalizing in that document. I suppose there's the argument for having a meaningful audit trail when things go wrong (instead of superuser hosing your site, it'd be "chrism"). But this is also a rationalization. I guess the ultimate answer is "shrug." I'm certainly not even going to think of trying to tear apart the code that makes it that way (nevermind the flamefest it would cause). Rather, to ameliorate the situation, Zope should prompt the installer to define a separate management user at setup.
Come to thing of it, is there a concise description anywhere of what the new rules are WRT to ownership, the logged in user and how 'code' of all the various types is executed?
What isn't covered in that document that you'd like to know?
Urm, again, no offence ('cos I think the book is aimed at a different audience) but the keyword for me was 'concise'. I did have a look at the document above, but didn't read it 'cos it looked about 10 pages long :-(
I'm looking for something closer to 10 _lines_ long, but that may not be possible ;-)
No. But the document is divided into sections, and one of those sections regards ownership. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
From: "Chris McDonough" <chrism@digicool.com>
On Mon, 4 Sep 2000, Chris Withers wrote:
Well, okay, let me rephrase the question: Why is it bad for the bootstrap user to own anything? It used to be considered okay before Zope 2.2, so was has been changed/discovered that makes this now such a bad idea that despite loads of newbie pain and confusion, it's still worth while/necessary?
I've got to say I agree with you here. I'm still not 100% sure why the superuser or bootstrap user can't own anything.
It's due to a combination of the trojan horse issue and the sticky authentication issue, I think. You really don't want to be authenticated as super very often, because while you are, if you visit a page someone else wrote, they can make your browser do evil things to your site. This is also true of Managers, but less so. Similarly, a page owned by non-super has tighter permissions than one owned by the super would. Ideally, people working in a site should be operating with the bare minimum of privileges to get the job done. The super should only be called in when no one else can fix it. Cheers, Evan @ digicool & 4-am
On Tue, 5 Sep 2000, Evan Simpson wrote:
I've got to say I agree with you here. I'm still not 100% sure why the superuser or bootstrap user can't own anything.
It's due to a combination of the trojan horse issue and the sticky authentication issue, I think. You really don't want to be authenticated as super very often, because while you are, if you visit a page someone else wrote, they can make your browser do evil things to your site. This is also true of Managers, but less so. Similarly, a page owned by non-super has tighter permissions than one owned by the super would.
Yes... the PDG security chapter has all of this in it, but it would seem that neither Chris W or I are completely satisfied by these answers. :-) It seems a matter of diminishing returns, especially when newbies hit the wall during install, since we haven't provided them with an airbag yet. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
Hi, Chris McDonough wrote:
On Tue, 5 Sep 2000, Evan Simpson wrote:
I've got to say I agree with you here. I'm still not 100% sure why the superuser or bootstrap user can't own anything.
It's due to a combination of the trojan horse issue and the sticky authentication issue, I think. You really don't want to be authenticated as super very often, because while you are, if you visit a page someone else wrote, they can make your browser do evil things to your site. This is also true of Managers, but less so. Similarly, a page owned by non-super has tighter permissions than one owned by the super would.
Yes... the PDG security chapter has all of this in it, but it would seem that neither Chris W or I are completely satisfied by these answers. :-) It seems a matter of diminishing returns, especially when newbies hit the wall during install, since we haven't provided them with an airbag yet.
Uhm. In the changes.txt there is mentioned that something had to be changed for tighter security. "The superuser can not own" is the same thing like not working with root privilegues on any unix system or log in as such. May be one should write it in <H1> all over the page where the download of zope is ;-) That may be the confusing part: one has to read while working with mostly text based applications ;-) Ok, the switching of user context is a bit painful with current authentication. One has to close all instances of the browser and reopen to log in as new user. May be the log-out-trick with the forced "unauthorized" response could help. Sometimes it is better to force people to think about security instead of having them complain after a break in about a faulty product. just my 0.02 penny ;-) Regards Tino
Chris McDonough wrote:
On Tue, 5 Sep 2000, Evan Simpson wrote:
I've got to say I agree with you here. I'm still not 100% sure why the superuser or bootstrap user can't own anything.
It's due to a combination of the trojan horse issue and the sticky authentication issue, I think. You really don't want to be authenticated as super very often, because while you are, if you visit a page someone else wrote, they can make your browser do evil things to your site. This is also true of Managers, but less so. Similarly, a page owned by non-super has tighter permissions than one owned by the super would.
Yes... the PDG security chapter has all of this in it, but it would seem that neither Chris W or I are completely satisfied by these answers. :-) It seems a matter of diminishing returns, especially when newbies hit the wall during install, since we haven't provided them with an airbag yet.
I think this is exlusively because as of 2.2.1 objects execute according to their ownership, not according to the permissions of the AUTHENTICATED_USER. Because of the widespread security implications of letting an object that can be called by anyone have superuser permissions (which was not possible under the prior regime), superuser can no longer own. You can still get superuser-esque behavior by doing something in external methods or some other mechanism that bypasses the security machinery. -- ethan mindlace fremen Zopatista Community Liason Abnegate I!
Chris Withers wrote:
Well, okay, let me rephrase the question: Why is it bad for the bootstrap user to own anything? It used to be considered okay before Zope 2.2, so was has been changed/discovered that makes this now such a bad idea that despite loads of newbie pain and confusion, it's still worth while/necessary?
Objects used to execute according to the permissions of the AUTHENTICATED_USER or the proxy role. "Ownership" only applied (for execution purposes) if you explicitly set the proxy role to "Owner". This was a Very Bad Thing (tm) because once you authenticated as superuser you could view a random HTML page on the web/in your inbox that had a little javascript thingy that went and wiped out your entire site or <insert maliciousness here> Now every object excecutes according to the permision of the owner, *not* the viewer. It can also run as a proxy role. The super-bootstrap-user lives outside of "normal" zope authentication & has permission to do anything save that which NotEvenGodShouldDo. Therefore, it shouldn't own objects. This is *quite* important, and needs to stay. I don't know how to emphasize enough that this is a well thought out correction to an extremely deadly class of security problems that still (afaik) plagues many "other" through-the-web management systems. The newbie pain, however, could probably be mitigated- don't call it a Super user, since it hardly deserves the S or the cape. Have a user in the default install. Something like that. Patches accepted. -- ethan mindlace fremen Zopatista Community Liason Abnegate I!
On Tue, 5 Sep 2000, ethan mindlace fremen wrote:
Now every object excecutes according to the permision of the owner, *not* the viewer. It can also run as a proxy role. The super-bootstrap-user lives outside of "normal" zope authentication & has permission to do anything save that which NotEvenGodShouldDo. Therefore, it shouldn't own objects.
Methods actually now execute with the effective intersection of the permissions granted to the AUTHENTICATED_USER and the permissions granted to the method's owner. If a proxy role is specified, the method executes with permissions restricted to those roles assigned by the proxy role. This is unarguably a good thing. What's not entirely clear is *why* super can't own, which is a separate issue. The power it has beyond that of a normal management user is the ability to traverse the site unrestricted by the security machinery. I actually don't think there's an answer to this question that has to do with method execution. I think the ultimate answer is one or a few of the following: "because," "shrug," "for audit trail purposes," or "so you don't shoot yourself in the foot," or "be quiet." :-) Alternately, the answer might lie in an unobvious implementation detail that none of us really want to think about.
This is *quite* important, and needs to stay. I don't know how to emphasize enough that this is a well thought out correction to an extremely deadly class of security problems that still (afaik) plagues many "other" through-the-web management systems.
I just can't think of any situations where having a method execute with the effective intersection of the permissions granted to superuser and the permissions granted to another user would cause more damage than a method executing with the effective intersection of the permissions granted to a normal management user and another user. Can you?
The newbie pain, however, could probably be mitigated- don't call it a Super user, since it hardly deserves the S or the cape. Have a user in the default install. Something like that.
I agree. This should happen soon. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
With the advent of Zope 2.2, the first thing you need to do is to create a management user. You cannot use the 'superuser' to manage content. I know this is a little unfamiliar, but, for now, just suspend disbelief and create another user with the 'Manager' role (by visiting the acl_users User Folder and adding a user). Then quit the browser, and log in as the user you created. You'll then be able to follow the cmg.
Couldn't the zope install be modified to prompt for a 'Manager' username and password and then create that account from the outset?
"Mark A. Pappas" wrote:
I installed Zope 2.2.0 on a Win 98 machine. Seems to work fine. I dloaded the Content Manager Guide and started working through the tutorial. Went to create a folder as instructed.
Below is what I got. What am I doing wrong?
Error Type: SuperCannotOwn Error Value: Objects cannot be owned by the superuser
You are working as superuser. While this *did* work up to Zope 2.1.6, since Zope 2.2 the security model was tightened. You must (as superuser) create a user with manage privilege, restart your browser and use that user to create objects. HTH, Jan
participants (8)
-
Chris McDonough -
Chris Withers -
ethan mindlace fremen -
Evan Simpson -
Jan H. Haul -
Mark A. Pappas -
Steve Drees -
Tino Wildenhain