4 ms·
Great blog post. Sometimes it's useful while testing to set random future and past times on Unix systems to see how programs handle that. https://blog.darkinfo
by hwskdjf 4y ago
Great blog post. Sometimes it's useful while testing to set random future and past times on Unix systems to see how programs handle that.
https://blog.darkinfo.org/timestomp-for-linux/ https://blog.darkinfo.org/timestomp-for-linux/
- pfarrell 4y agoMongodb, for one, will freak out if you set the system date into the future, interact with it, then set time back. It will think the indices are corrupt and refuse to start. At least that happened to me last year. IIRC, the time stamp is part of generated object ids, so it’s sort of understandable. In the end I returned by computer to the future date, exported data, and rebuilt my collections.
- samatman 4y agoSo anyone can bring down Mongo with a compromised ntp server? That's an inconvenient property to have.
- _jal 4y agoOh, if you own someone's clock, you can do all sorts of damage. Want to expire everyone's passwords? Blow up their credit card processing? Those are just the obvious attacks.
- samatman 4y agoYes but bringing down a database should not be among those things. Surely we can agree on that.
- macintux 4y agoI’m curious whether there is any database that handles this scenario correctly…or even whether there is a correct behavior for a situation where the system clock is rewound.
- pfarrell 4y agoGood question. I used to test an auction app I maintained on SqlServer but I never pushed it more than a few hours into the future. To be clear: my experience with MongoDb was a one off local issue. No idea if there are server protections etc.