Through a zwiki a spammer proxied some information though a zope server using zwiki's comments (be aware!). The spammer had dated his ip-packets 11/12-2007. And all my changes got the same date! So, I couldn't shrink all the undo actions though the database shrinker (later I found out that should just use -300). To get rid of 10 GB of undo history, I changed the computers time to 12/12-2007 and then undoed and gave the computer the right time again. Fine! But, now, not only have all my changes the date 12/12-2007 in the undo history, every object I have changed gets this date as well! Apparently, zope won't accept to go backward in time. How do I reset the zope's time? DateTime().Date() gives the right time. Flemming
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Mar 2007, at 17:11, flem wrote:
Through a zwiki a spammer proxied some information though a zope server using zwiki's comments (be aware!). The spammer had dated his ip-packets 11/12-2007. And all my changes got the same date! So, I couldn't shrink all the undo actions though the database shrinker (later I found out that should just use -300). To get rid of 10 GB of undo history, I changed the computers time to 12/12-2007 and then undoed and gave the computer the right time again. Fine!
But, now, not only have all my changes the date 12/12-2007 in the undo history, every object I have changed gets this date as well! Apparently, zope won't accept to go backward in time.
How do I reset the zope's time?
Undo is transactional, meaning an undo is actually a new transaction instead of removing an old transaction. What you are trying to do is not possible, unless you physically truncate the database. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGArLnRAx5nvEhZLIRAob1AKCRrTDJ8IMwT+6IuEJvFBOszyz7/QCgrl+O JbXq1Qo7v8jkY3ivN67RZTo= =pYwG -----END PGP SIGNATURE-----
On Thu, 22 Mar 2007 17:46:31 +0100 Jens Vagelpohl <jens@dataflake.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22 Mar 2007, at 17:11, flem wrote:
Through a zwiki a spammer proxied some information though a zope server using zwiki's comments (be aware!). The spammer had dated his ip-packets 11/12-2007. And all my changes got the same date! So, I couldn't shrink all the undo actions though the database shrinker (later I found out that should just use -300). To get rid of 10 GB of undo history, I changed the computers time to 12/12-2007 and then undoed and gave the computer the right time again. Fine!
But, now, not only have all my changes the date 12/12-2007 in the undo history, every object I have changed gets this date as well! Apparently, zope won't accept to go backward in time.
How do I reset the zope's time?
Undo is transactional, meaning an undo is actually a new transaction instead of removing an old transaction. What you are trying to do is not possible, unless you physically truncate the database.
I am not absolutely sure I understand you. I succeeded in undoing. My problem is that zope keeps on with the date 12/12-07. The zodb does not seem to accept a timestamp that is earlier than the last ... Flemming
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Mar 2007, at 07:41, Flemming Bjerke wrote:
But, now, not only have all my changes the date 12/12-2007 in the undo history, every object I have changed gets this date as well! Apparently, zope won't accept to go backward in time.
How do I reset the zope's time?
Undo is transactional, meaning an undo is actually a new transaction instead of removing an old transaction. What you are trying to do is not possible, unless you physically truncate the database.
I am not absolutely sure I understand you. I succeeded in undoing. My problem is that zope keeps on with the date 12/12-07. The zodb does not seem to accept a timestamp that is earlier than the last
That's what I am trying to tell you. Any undo is actually a brand-new transaction that will by definition set the modification time to the current time. You *cannot* get back to the old modification time using Undo. This does not mean that Undo won't work at all, it will. But you will not get back your old modification time. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGA4XFRAx5nvEhZLIRAtVgAKCzR9Chwxwne5A0ncA0kyuckiLH4wCgr0oQ 5jNmLYQn4p8fdBzNV3ALU5M= =AbR8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Vagelpohl schrieb:
On 23 Mar 2007, at 07:41, Flemming Bjerke wrote:
But, now, not only have all my changes the date 12/12-2007 in the undo history, every object I have changed gets this date as well! Apparently, zope won't accept to go backward in time.
How do I reset the zope's time?
Undo is transactional, meaning an undo is actually a new transaction instead of removing an old transaction. What you are trying to do is not possible, unless you physically truncate the database.
I am not absolutely sure I understand you. I succeeded in undoing. My problem is that zope keeps on with the date 12/12-07. The zodb does not seem to accept a timestamp that is earlier than the last
That's what I am trying to tell you. Any undo is actually a brand-new transaction that will by definition set the modification time to the current time. You *cannot* get back to the old modification time using Undo. This does not mean that Undo won't work at all, it will. But you will not get back your old modification time.
jens
so it migth be enough, to export the folder(s) with your sites remove the Data.fs to a secure place, restart zope and the reimport your sites. just an idea robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGA4lfGaryJ0T9kUYRAoKMAJ97ooj+qxLZ5yA6kjk++w3iTj1xDgCfReFA 29pvh80BOjil2GPXxXurhdg= =92Fr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Mar 2007, at 09:01, robert rottermann wrote:
I am not absolutely sure I understand you. I succeeded in undoing. My problem is that zope keeps on with the date 12/12-07. The zodb does not seem to accept a timestamp that is earlier than the last
That's what I am trying to tell you. Any undo is actually a brand-new transaction that will by definition set the modification time to the current time. You *cannot* get back to the old modification time using Undo. This does not mean that Undo won't work at all, it will. But you will not get back your old modification time.
so it migth be enough, to export the folder(s) with your sites remove the Data.fs to a secure place, restart zope and the reimport your sites.
No. Import will also generate new database modification times. It will only make things worse. This issue appears when product authors naively use the database modification time instead of defining their own field in which to store modification time data. They would have full control if they used their own time stamps. Most product authors simply don't know what the possible consequences are, or when/how the database modification timestamps are changing. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGA4nrRAx5nvEhZLIRAlo3AJ9sAB/CpqgctBryDQD5vSvTjVqLMwCeOmUo AUy0tEmUBi9fmTj5pWEOYm4= =0wAy -----END PGP SIGNATURE-----
On Fri, 23 Mar 2007 09:03:55 +0100 Jens Vagelpohl <jens@dataflake.org> wrote:
No. Import will also generate new database modification times. It will only make things worse.
This issue appears when product authors naively use the database modification time instead of defining their own field in which to store modification time data.
I don't think the zwiki-people know this.
They would have full control if they used their own time stamps. Most product authors simply don't know what the possible consequences are, or when/how the database modification timestamps are changing.
I am a bit confused. My zopeserver runs fine, and all undos have been erased. What I want is to be able to create an object in the zmi which has the correct creation date (e.g. 23rd March 12.20 pm) in the zmi (and the undo history as well). Is this simply impossible because the timestamp in the zodb is always automatically adjusted to the latest date associated to the objects already created (i.e. 12th December 2007)? Flemming
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Mar 2007, at 12:20, flem wrote:
I am a bit confused. My zopeserver runs fine, and all undos have been erased. What I want is to be able to create an object in the zmi which has the correct creation date (e.g. 23rd March 12.20 pm) in the zmi (and the undo history as well). Is this simply impossible because the timestamp in the zodb is always automatically adjusted to the latest date associated to the objects already created (i.e. 12th December 2007)?
You hit the nail on the head. The ZODB timestamp is adjusted whenever the ZODB record for an object is changed and the application code has _no_ control over it. Such change could be effected by a content author editing the object, or by an import, or by an undo operation. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGA9BzRAx5nvEhZLIRAtWEAJ0Wi2op0pbepzPUc+z2Njt4hOtImwCffqxA fKsoxuBL4drthkAIkvQz6Dg= =yOWK -----END PGP SIGNATURE-----
On Fri, 23 Mar 2007 14:04:51 +0100 Jens Vagelpohl <jens@dataflake.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23 Mar 2007, at 12:20, flem wrote:
I am a bit confused. My zopeserver runs fine, and all undos have been erased. What I want is to be able to create an object in the zmi which has the correct creation date (e.g. 23rd March 12.20 pm) in the zmi (and the undo history as well). Is this simply impossible because the timestamp in the zodb is always automatically adjusted to the latest date associated to the objects already created (i.e. 12th December 2007)?
You hit the nail on the head. The ZODB timestamp is adjusted whenever the ZODB record for an object is changed and the application code has _no_ control over it. Such change could be effected by a content author editing the object, or by an import, or by an undo operation.
I think this kind af date-deadlock is a vulnerability of the zope architecture. Is it the same thing with zope3? Isn't it an unnecessary vulnerability that an open zwiki comments field - or any other object making act open to the public where the anyone can set the date - can corrupt the time system irrepairbly. Shouldn't there be some solutions: 1. A script could reset all relevant dates and the timestamp i the zodb. 2. The zope code should be changed so that the timestamp depended directly on the pc-clock notwithstanding the dates of the objects thus allowing for going backward in time. Flemming
--On 23. März 2007 16:09:15 +0100 flem <flem@bjerke.dk> wrote:
I think this kind af date-deadlock is a vulnerability of the zope architecture. Is it the same thing with zope3? Isn't it an unnecessary vulnerability that an open zwiki comments field - or any other object making act open to the public where the anyone can set the date - can corrupt the time system irrepairbly.
Shouldn't there be some solutions:
1. A script could reset all relevant dates and the timestamp i the zodb.
2. The zope code should be changed so that the timestamp depended directly on the pc-clock notwithstanding the dates of the objects thus allowing for going backward in time.
I am not getting the point. What do you want to tell us? -aj
On Fri, 23 Mar 2007 16:16:55 +0100 Andreas Jung <lists@zopyx.com> wrote:
--On 23. März 2007 16:09:15 +0100 flem <flem@bjerke.dk> wrote:
I think this kind af date-deadlock is a vulnerability of the zope architecture. Is it the same thing with zope3? Isn't it an unnecessary vulnerability that an open zwiki comments field - or any other object making act open to the public where the anyone can set the date - can corrupt the time system irrepairbly.
Shouldn't there be some solutions:
1. A script could reset all relevant dates and the timestamp i the zodb.
2. The zope code should be changed so that the timestamp depended directly on the pc-clock notwithstanding the dates of the objects thus allowing for going backward in time.
I am not getting the point. What do you want to tell us?
That I think it is a vulnerability that a person can irrepairably corrupt zope's date system by sending one request with a wrong date (in my case using the default open comment opportunity in zwiki). Is this a vulnerability that also exists in zope3? Flemming
Flemming Bjerke schrieb:
On Fri, 23 Mar 2007 16:16:55 +0100 Andreas Jung <lists@zopyx.com> wrote:
--On 23. März 2007 16:09:15 +0100 flem <flem@bjerke.dk> wrote:
I think this kind af date-deadlock is a vulnerability of the zope architecture. Is it the same thing with zope3? Isn't it an unnecessary vulnerability that an open zwiki comments field - or any other object making act open to the public where the anyone can set the date - can corrupt the time system irrepairbly.
Shouldn't there be some solutions:
1. A script could reset all relevant dates and the timestamp i the zodb.
2. The zope code should be changed so that the timestamp depended directly on the pc-clock notwithstanding the dates of the objects thus allowing for going backward in time.
I am not getting the point. What do you want to tell us?
That I think it is a vulnerability that a person can irrepairably corrupt zope's date system by sending one request with a wrong date (in my case using the default open comment opportunity in zwiki).
Well, but this one can't be truth. ZODB time stamps are generated in the ZODB layer and not taken from request. In fact, the concept of a request is completely unknown to ZODB. Regards Tino
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Mar 2007, at 09:03, Flemming Bjerke wrote:
That I think it is a vulnerability that a person can irrepairably corrupt zope's date system by sending one request with a wrong date (in my case using the default open comment opportunity in zwiki).
There is no "vulnerability". I think you're confusing a few things. All I read from your description is that you, as the admin, used Undo and even mucked with your database while having set the server to a different time. That's no vulnerability, that's the admin user messing with the database. Requests don't have anything to do with either the ZODB time stamp or any application time stamp. You should take a look at the code and gain some better understanding of how the Wiki code generates or uses dates. Date stamps are generated by taking the time as set on the host machine. They are not generated from requests sent to the server. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGBOm+RAx5nvEhZLIRAtOSAKCVrIpcYvZ/Nh0COEYn3scAbkmWlwCgropL mVFgB/Qyn+mUNZLqzUqhbWE= =Obim -----END PGP SIGNATURE-----
(Fri, Mar 23, 2007 at 09:03:55AM +0100) Jens Vagelpohl wrote/schrieb/egrapse:
This issue appears when product authors naively use the database modification time instead of defining their own field in which to store modification time data. They would have full control if they used their own time stamps. Most product authors simply don't know what the possible consequences are, or when/how the database modification timestamps are changing.
Zwiki of course uses its own timestamp attribute: last_edit_time The original poster likely got in this mess by not using the Zwiki methods to mass-revert the stuff. Regards, Sascha
On Fri, Mar 23, 2007 at 04:52:18PM +0100, Sascha Welter wrote:
(Fri, Mar 23, 2007 at 09:03:55AM +0100) Jens Vagelpohl wrote/schrieb/egrapse:
This issue appears when product authors naively use the database modification time instead of defining their own field in which to store modification time data. They would have full control if they used their own time stamps. Most product authors simply don't know what the possible consequences are, or when/how the database modification timestamps are changing.
Zwiki of course uses its own timestamp attribute: last_edit_time
The original poster likely got in this mess by not using the Zwiki methods to mass-revert the stuff.
Moral of the story is: don't do insane things with your system clock, the results are undefined. More generally, don't try giant shotgun workarounds ... a) if you don't know what the effects will be b) if you don't really understand your original problem c) if you don't have a backup in case your "solution" causes a bigger problem Flem, I'm sorry this happened to you, but sorry to say your attempted solution was a really bad idea and it's not really fair to blame the software for that. The best thing you could do is restore from the backup you made before you messed with the system clock. If you didn't make one, you may have to truncate the database to a transaction previous to when all this happened. Make another backup copy of Data.fs before doing that, of course. The basic idea is: find the position in the Data.fs file that contains the first transaction that occurred at your "in the future" date, and delete the rest of the file after that point. This is assuming you haven't already packed the database and thrown away the old transactions you want to recover. There isn't really an "official" way to truncate as far as I know, and I don't remember the details, but the links here might help (look under the word "truncate"): http://wiki.zope.org/zope2/ZODB Also check the archives of the zodb-dev mailing list, there has been some recent discussion of ways to truncate the database file, the topic was "roll back filestorage zodb to a certain date". lib/python/ZODB/fsrecover.py may be helpful for finding those transactions. -- Paul Winkler http://www.slinkp.com
participants (8)
-
Andreas Jung -
flem -
Flemming Bjerke
-
Jens Vagelpohl -
Paul Winkler -
robert rottermann -
Sascha Welter -
Tino Wildenhain