Versions: should they die?
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here. Comments? Could we get at least some warnings in the ZMI before 2.6.2 final? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE COSMIC! (random hero from isometric.spaceninja.com)
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here.
Comments? Could we get at least some warnings in the ZMI before 2.6.2 final?
IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI! --Guido van Rossum (home page: http://www.python.org/~guido/)
IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI!
I think its worth pointing out that the main part of the problem with versions is how they are implemented in Zope 2, not as they exist in the ZODB. It might be fine and useful in the ZODB, in fact I remember some use cases Jeremy pointed out that did sound useful. The main problem really is the Zope implementation for example: you can lock any object in a version that doesn't exists, it uses cookies, trouble committing... etc. -- Andy McKay
Guido van Rossum wrote IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI!
Worse yet, they _seem_ like a neat/useful solution. But they're not - it's a path that leads to madness and despair. I'd prefer the approach of making you change some code in lib/python/ to enable them, with them disabled by default. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Paul Winkler wrote:
Comments?
They really should die. They cause nothing but pain and suffering.
Could we get at least some warnings in the ZMI before 2.6.2 final?
I do hope so. I'd also like to see them becoming an explicit configuration option in 2.7 and not appear in any UI's unless they have been explicitly turned on... Perhaps Jeremy could run through his reasons for wanting them to stay around again? cheers, Chris
Perhaps Jeremy could run through his reasons for wanting them to stay around again?
That's not necessary. They could stay in ZODB (certainly cutting them out of ZODB3 now would be more work than leaving them in) but be disabled in ZMI. --Guido van Rossum (home page: http://www.python.org/~guido/)
Sorry if is OT. I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed. Does the Version mechanism contribute to this kind of functionality? I'd like to be able to "tag" revisions of wiki pages and other documents, and then be able to diff them later without having to create a special kind of product for each object type that I'd like to use revisions for. Maybe this is kind of the reverse way of doing what versions are for. We have used versions a little to work on a "live site". What would be interesting is using revisions (with tags), then telling Zope to serve only objects with this revision or "older", or the current object if no revisions are on file for that object. And .. the serving up of a particular tag would be set on a Zserver instance. So, I could continue to use ZMI as normal, but run "another zserver" on a different port (the one that feeds the world) with a particular revision. Or I could do this with ZEO. Probably there's too much overhead in this idea. -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
On Wednesday 04 June 2003 17:40, Brad Clements wrote:
Sorry if is OT.
I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed.
DirectoryStorage allows you to designate classes that should have all their history kept indefinitely. That may not have the flexibility that you need...
Does the Version mechanism contribute to this kind of functionality? I'd like to be able to "tag" revisions of wiki pages and other documents, and then be able to diff them later without having to create a special kind of product for each object type that I'd like to use revisions for.
The accepted wisdom is that feature like this should be implemented in the application, above zodb. This has come up a few times on zodb-dev list. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Sorry if is OT.
I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed.
DirectoryStorage allows you to designate classes that should have all their history kept indefinitely. That may not have the flexibility that you need...
Does the Version mechanism contribute to this kind of functionality? I'd like to be able to "tag" revisions of wiki pages and other documents, and then be able to diff them later without having to create a special kind of product for each object type that I'd like to use revisions for.
The accepted wisdom is that feature like this should be implemented in the application, above zodb. This has come up a few times on zodb-dev list.
There are extant app-space version-control implementations if you want to try them. They don't do the full range of things that, say, CVS does, but they aren't chopped liver either. Look for ZopeVersioning and CMFStaging. Both can be (at least) browsed at cvs.zope.org --jcc
Brad Clements wrote:
Sorry if is OT.
I'd like ZODB and Zope to support Revisions. That is, historical copies that do not get removed when ZODB is packed.
Does the Version mechanism contribute to this kind of functionality?
No, not really. Maybe it can be coached into doing it, but not without much ado.
Maybe this is kind of the reverse way of doing what versions are for. We have used versions a little to work on a "live site".
That seems to be the only use for it, being able to make several updates on a site without the updates being seen. It's not a bad feature, but it's too limited for much of the use, where you instead want revisions of objects and workflows where you can stage the piublishing of different revisions. And for doing that you have no use of the ZODB versions at all, as they are done today. You are better off using multiple instances of the objects, one for each revision, and then creating a staging workflow with DCWorkflow.
So, I could continue to use ZMI as normal, but run "another zserver" on a different port (the one that feeds the world) with a particular revision. Or I could do this with ZEO.
Probably there's too much overhead in this idea.
Well, it's too much overhead in doing it with ZODB, yes.
Paul Winkler wrote:
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here.
Well, as they are, even when they are working, they are practically useless, since almost all even slightly complex use of Zope involves catalogs, and when using versions and catalogs, the catalog immediately gets blocked from outside change as soon as you reindex something in a version. So I have no problems with versions getting dropped altogether in 2.7. To have versions you really need a way to branch object versions and then merge them again. This COULD be implemented in the ZODB, but it might just as well be implemented on a higher level, and I'm not completely sure that the ZODB solution is wrong. But it is not nessecary.
Comments? Could we get at least some warnings in the ZMI before 2.6.2 final?
I think that would be good.
Paul Winkler wrote:
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here.
Comments? Could we get at least some warnings in the ZMI before 2.6.2 final?
As I see it, you either have to disable the versioning functionality completely, or live with it. Raising a warning when people for instance add a Version object just gives the impression that you are safe if you don't use the Version product, which is wrong. If the version functionality would be disabled by default and could be enabled by a startup parameter without impacting performance, then this would be the way to go IMHO. cheers, oliver
Paul Winkler wrote at 2003-6-3 14:00 -0400:
... It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. ... Comments?
-3 I like versions and use them from time to time to automically install changes on life servers. Without versions, I would need to work more often late at night (when I usually read Zope mailing lists ;-) ). Dieter
Ok, I still have the impression that not enough people are aware of the full implications of the version functionality as it is implemented in zope. So let me summarize. versioning-as-implemented-in-zope consists of two parts: First, there's the database backend part (which I know nothing about) with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). This resides where the db-connection is opened on the very start of every request. The second part is the Version product (capitalized to distinguish them) which is zope's mechanism to get a variable named 'Zope-Version' (==version_support) with the value of the path to the version object inside the REQUEST (by setting a cookie). Bad properties of this implementation: 1. The "Join/Leave Versions" permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition. Security implications: Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos. Big plea: Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone. Sorry for getting a bit worked up about that issue. cheers, oliver
One man's opinion: - Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them. I would suggest these approaches: 1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon. 2: develop a patch and submit it and/or check it in probably after vetting the change on a branch. I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself. The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6. -Casey On Friday 06 June 2003 05:46 am, Oliver Bleutgen wrote:
Ok, I still have the impression that not enough people are aware of the full implications of the version functionality as it is implemented in zope. So let me summarize.
versioning-as-implemented-in-zope consists of two parts:
First, there's the database backend part (which I know nothing about) with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). This resides where the db-connection is opened on the very start of every request.
The second part is the Version product (capitalized to distinguish them) which is zope's mechanism to get a variable named 'Zope-Version' (==version_support) with the value of the path to the version object inside the REQUEST (by setting a cookie).
Bad properties of this implementation:
1. The "Join/Leave Versions" permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition.
Security implications:
Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos.
Big plea:
Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone.
Sorry for getting a bit worked up about that issue.
cheers, oliver
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Casey Duncan wrote:
One man's opinion:
- Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them.
I would suggest these approaches:
1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon.
I had a bug in the collector for that in the 2.3.x times, before the db crashed, IIRC. I fear I'm bad at explaining the issue clear enough, so nobody cared.
2: develop a patch and submit it and/or check it in probably after vetting the change on a branch.
I have definately not enough knowledge to get a fix for that which is acceptable speedwise. And removing the version support is probably not what you want ;).
I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself.
This is not my favorite issue, non of my sites is really affected by this because there only trusted users are able to write to the ZODB, so they could do much more harm in simpler ways.
The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply.
This is the important thing that doesn't seem to get through. These implications _do_ apply! I would be very suprised if I wouldn't be able to inject versioned objects into zope.org, collector.zope.org or squishdot.org for example. cheers, oliver
Casey Duncan wrote:
The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6.
My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity. I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie and disabling the creation of Version objects, with an option to re-enable. Shane
Aaah, big thanks for chiming in. *sigh of relief*. Shane Hathaway wrote:
Casey Duncan wrote:
The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6.
My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches.
It's even worse. Just add &Zope-Version=bla to your (or anyone elses) request, maybe handy for client side scripting attacks.
Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity.
Well, there's still ControlPanel->Version Management, but you have first to know that it exists ;). Had that problem when this hit me quite a while ago.
I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie and disabling the creation of Version objects, with an option to re-enable.
+1 cheers, oliver
On Friday 06 June 2003 15:04, Shane Hathaway wrote:
I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie
Setting this individually for each http port would better support existing happy users of this feature. (Im sure there must be some ;-) Being able to set up a port that ignored cookies but always used a specific Version would avoid many of the existing problems too. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Shane Hathaway wrote:
My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity.
This was my fear, and it's pretty shocking. Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-) (not Squishdot.org please, I'm not a ZODB expert and I don't haev the expertise to fix this bug :-S)
I think 2.6 ought to fix this by disabling recognition of the Zope-Version cookie and disabling the creation of Version objects, with an option to re-enable.
Yes indeed! Chris
Chris Withers wrote:
Shane Hathaway wrote:
My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc.
On the weekend I had the idea that it's even easier. See http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 how to do that on an zope server.
All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity.
This was my fear, and it's pretty shocking.
Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-)
Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer not to get ;). cheers, oliver
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Oliver Bleutgen Sent: Tuesday, June 10, 2003 7:35 AM To: zope-dev@zope.org Subject: Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Chris Withers wrote:
Shane Hathaway wrote:
My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc.
On the weekend I had the idea that it's even easier. See http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 how to do that on an zope server.
All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity.
This was my fear, and it's pretty shocking.
Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-)
Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer not to get ;).
cheers, oliver
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Brian Lloyd wrote:
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default.
It will be interesting to find out how this can be accomplished. To use a version, you have to specify the version at the time of opening the database. Before opening the database, the application has no access to user accounts, let alone security settings. I really wouldn't mind if we just disabled version support altogether, with a configuration option to re-enable it. Perhaps users would appreciate having less to worry about. Shane
Shane Hathaway wrote:
Brian Lloyd wrote:
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default.
It will be interesting to find out how this can be accomplished. To use a version, you have to specify the version at the time of opening the database. Before opening the database, the application has no access to user accounts, let alone security settings.
And you have to take acquisition into account folder1 some_object folder2 version2 some_object shouldn't be lockable into version2. cheers, oliver
Oliver Bleutgen wrote at 2003-6-10 16:20 +0200:
... And you have to take acquisition into account
folder1 some_object folder2 version2
some_object shouldn't be lockable into version2.
Where did you ever read that the effect of versions were in any way restricted in correspondence with their own path? A version affects the complete site (independent from where in the hierarchy they live). I make use of this "feature". My versions are located in a utility folder "Administration", but they should allow me to make fixes and installations all over the site. Dieter
Dieter Maurer wrote:
Oliver Bleutgen wrote at 2003-6-10 16:20 +0200:
... And you have to take acquisition into account
folder1 some_object folder2 version2
some_object shouldn't be lockable into version2.
Where did you ever read that the effect of versions were in any way restricted in correspondence with their own path?
You are right. I hadn't looked at this code for a long time, now I checked in cvs, and this was changed (ca. 2 years ago). Now zope sends BASEPATH1 as cookie path, which makes the cookie indeed global. cheers, oliver
Shane Hathaway wrote:
I really wouldn't mind if we just disabled version support altogether, with a configuration option to re-enable it. Perhaps users would appreciate having less to worry about.
I still think this is the best idea. If this is not possible, then at least removing it from the UI, with an option to get it back would be fine, becuase most problems are not because of Version usage via HTTP (even if this is a problem also).
Shane Hathaway wrote:
Brian Lloyd wrote:
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default.
It will be interesting to find out how this can be accomplished. To use a version, you have to specify the version at the time of opening the database. Before opening the database, the application has no access to user accounts, let alone security settings.
Right, but you can always abort the transaction later. I simply added some logic in the zpublisher_validated_hook to check if the request includes the version variable and, if so, to check whether the user has the join/leave version permission *globally*. If they don't, I clear the cookie and raise unauthorized. Unfortunately, this is not backward compatible because, with this change, a user can't be given a local role that lets them join/leave versions. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (703) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Shane Hathaway wrote at 2003-6-10 10:15 -0400:
Brian Lloyd wrote:
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the "join / leave versions" permission (which is assigned only to managers by default.
It will be interesting to find out how this can be accomplished. To use a version, you have to specify the version at the time of opening the database. Before opening the database, the application has no access to user accounts, let alone security settings.
Let it open the version, perform the traversal and after authentication, check that it was justified. If not, abort the request. Dieter
Oliver Bleutgen wrote at 2003-6-6 11:46 +0200:
... Bad properties of this implementation:
1. The "Join/Leave Versions" permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition.
Security implications:
Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos.
Big plea:
Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone.
1. is difficult to change. When we had a post-authentication hook (a hook called by ZPublisher after authentication has been done), then we could check in this hook that the user has the right to enter the version. Such a hook would be extremely helpful for other applications, too. 2. would be easy to fix. I already posted an outline for the check. 3. is already implemented correctly (I think). Dieter
Dieter Maurer wrote:
Oliver Bleutgen wrote at 2003-6-6 11:46 +0200:
3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition.
3. is already implemented correctly (I think).
I doubt it, since the code which causes the opening of a versioned db connection doesn't know anything about the path semantics of the value of 'Zope-Version'. Let's say you have aMethod aFolder aVersion and have entered the version at aFolder/aVersion and POST to aFolder/aMethod/manage_doSomething (manage_doSomething changes aMethod) your browser will send a 'Zope-Version' cookie with value 'aFolder/aVersion' (standards conform, since you are requesting an URL below '/aFolder', the path of this 'Zope-Version' cookie), and aMethod will be locked in that version. Not tested, but I would take a bet. cheers, oliver
Oliver Bleutgen wrote at 2003-6-6 22:48 +0200:
Dieter Maurer wrote:
Oliver Bleutgen wrote at 2003-6-6 11:46 +0200:
3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition.
3. is already implemented correctly (I think).
I doubt it, since the code which causes the opening of a versioned db connection doesn't know anything about the path semantics of the value of 'Zope-Version'.
There is no "path semantics" in the "Version" value. I never read that there should be one. Dieter
Dieter Maurer wrote:
When we had a post-authentication hook (a hook called by ZPublisher after authentication has been done), then we could check in this hook that the user has the right to enter the version.
When did we have one? Where did it go?
Such a hook would be extremely helpful for other applications, too.
Yeah, a specific example that springs to mind is the selection of a CMF skin based on a user's role... cheers, Chris
Chris Withers wrote at 2003-6-10 13:24 +0100:
Dieter Maurer wrote:
When we had a post-authentication hook (a hook called by ZPublisher after authentication has been done), then we could check in this hook that the user has the right to enter the version.
When did we have one? Where did it go?
English is difficult and it is not my mother tongue. I meant: If we had (would have) a post-authentication hook ... We had discussed the post-authentication hook in connection with role based skin selection but we never had it implemented.
Such a hook would be extremely helpful for other applications, too.
Yeah, a specific example that springs to mind is the selection of a CMF skin based on a user's role...
Indeed. That where the post-authentication hook idea came into existence... Dieter
Dieter Maurer wrote:
We had discussed the post-authentication hook in connection with role based skin selection but we never had it implemented.
I have, and it even fits here in the margin. Shall I pop it into the Collector? 242a243
self._post_traverse = post_traverse = []
363a365
del self._post_traverse
434a437,439
if post_traverse: exec_callables(post_traverse)
444a450,453
def post_traverse(self, f, args): """Set a callable object and argument tuple to be combined if traversal succeeds""" self._post_traverse.append((f, tuple(args)))
445a455,470
def exec_callables(callables): for (f, args) in callables: try: f(*args) except (ArithmeticError, AttributeError, FloatingPointError, IOError, ImportError, IndexError, KeyError, OSError, OverflowError, TypeError, ValueError, ZeroDivisionError): # Only catch exceptions likely to be logic errors. # We shouldn't catch Redirects, Unauthorizeds, etc. since # the programmer may want to raise them deliberately. from zLOG import LOG, ERROR import sys LOG('PostTraverse', ERROR, 'Error while invoking hook: "%s"' % `f`, error=sys.exc_info())
Please do, I need it for some some extra authentication against a mysql db. Robert Am Dienstag, 10. Juni 2003 20:41 schrieb Evan Simpson:
Dieter Maurer wrote:
We had discussed the post-authentication hook in connection with role based skin selection but we never had it implemented.
I have, and it even fits here in the margin. Shall I pop it into the Collector?
242a243
self._post_traverse = post_traverse = []
363a365
del self._post_traverse
434a437,439
if post_traverse: exec_callables(post_traverse)
444a450,453
def post_traverse(self, f, args): """Set a callable object and argument tuple to be combined if traversal succeeds""" self._post_traverse.append((f, tuple(args)))
445a455,470
def exec_callables(callables): for (f, args) in callables: try: f(*args) except (ArithmeticError, AttributeError, FloatingPointError, IOError, ImportError, IndexError, KeyError, OSError, OverflowError, TypeError, ValueError, ZeroDivisionError): # Only catch exceptions likely to be logic errors. # We shouldn't catch Redirects, Unauthorizeds, etc. since # the programmer may want to raise them deliberately. from zLOG import LOG, ERROR import sys LOG('PostTraverse', ERROR, 'Error while invoking hook: "%s"' % `f`, error=sys.exc_info())
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch
Oliver Bleutgen wrote:
2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all.
Hmm, it doesn't care, but it does store it in memory. Pardon my fugly non-portable bashisms here, but I just wanted to hash out an example: #!/path/to/bash exec >/dev/null h='http://victim.example.com/' for i in `seq 100`; do w3m -dump -post <(perl -e 'print "Zope-Version=",$ARGV[0]x500000' $i) "$h" done Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc. Under sane resource limits the host is spared however the /Control_Panel/Database/manage_cacheParameters resource becomes unavailable due to memory constraints. Other side-effects from allowing anonymous clients to open additional zodb connections are as of yet unknown to me, anyone care to speculate on other vectors of abuse? -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
On Friday 06 June 2003 21:28, Jamie Heilman wrote:
Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc.
Attached is a temporary patch to block this denial of service attack. This patch applies cleanly to the trunk and the 2.6 branch. This patch works by blocking all access to versions in the publisher, so dont apply it if you cant afford to stop using versions -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev
Unless you're damning me with faint praise for posting an exploit, (which is fine) this issue was found by Oliver, not me. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
On Tuesday 10 June 2003 09:32, Jamie Heilman wrote:
Toby Dickenson wrote:
! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev
Unless you're damning me with faint praise for posting an exploit, (which is fine)
No criticism was implied.... public exploits are valuable part of the security process. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
No criticism was implied.... public exploits are valuable part of the security process.
Its nice to hear not everyone in the industry has lost their mind. /me glances at redmond -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Hi Toby, I am sorry, but the patch to disable versions does not work for me (using Zope 2.6.1 / Python2.1.3), maybe because of trivial typo:
=================================================================== RCS file: /cvs-repository/Zope/lib/python/ZODB/ZApplication.py,v retrieving revision 1.13 diff -c -2 -r1.13 ZApplication.py *** lib/python/ZODB/ZApplication.py 8 Apr 2003 18:48:22 -0000 1.13 --- lib/python/ZODB/ZApplication.py 9 Jun 2003 22:58:43 -0000 *************** *** 42,49 ****
def __bobo_traverse__(self, REQUEST=None, name=None): ! db, aname, version_support = self._stuff ! if version_support is not None and REQUEST is not None: ! version=REQUEST.get(version_support,'') ! else: version='' conn=db.open(version)
--- 42,53 ----
def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! # db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version)
This seems to comment out "db" and "aname", too. As one can see in the context of the diff, "db" is used in the very last line of the patch context. Zope gives me the NameError I would expect from the code when I send a request to the patched server. Dropping the comment from the line reading the "_stuff" seems to work for me:
--- 42,53 ----
def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version)
Cheers, Clemens
participants (19)
-
Andy McKay -
Anthony Baxter -
Brad Clements -
Brian Lloyd -
Casey Duncan -
Chris Withers -
Clemens Robbenhaar -
Dieter Maurer -
Evan Simpson -
Guido van Rossum -
J Cameron Cooper -
Jamie Heilman -
Jim Fulton -
Lennart Regebro -
Oliver Bleutgen -
Paul Winkler -
robert -
Shane Hathaway -
Toby Dickenson