> What we *can* do is instead add an extra declaration of system time > based on the build/release date of the particular version of the > fake-hwclock package in use, and refuse to back to a date before > *that* unless --force is used. How does that sound?
That sounds like a good policy in general, and it would solve my concerns. Thanks! On Fri, Apr 8, 2016 at 10:50 AM Steve McIntyre <st...@einval.com> wrote: > [ Including a CC to Robie from the previous bug #763589... ] > > Hey guys, > > On Tue, Mar 22, 2016 at 11:37:56PM +0000, Roddy Shuler wrote: > >Package: fake-hwclock > >Version: 0.10 > > > >On bug #763589, protection was added around the save operation so that the > >saved time cannot go backwards without forcing. While this clearly > >mitigates the race condition of concern, I don't believe it is an > >acceptable solution for normal users. > > > >Consider the following use case... > > > >1. The user accidentally sets a wrong time to a date in the future -- for > >example, sets the year to 2017 rather than 2016 > >2. The fake-hwclock.data file is written with the future time > >3. The user then realizes the mistake, and tries to fix the time back to > >the year 2016 > >4. Now, the cron job and service will not update the fake-hwclock.data, > >since it appears that the current system time is in the past (relative to > >the invalid saved time) > >5. On reboot, the clock reverts to the future date in the year 2017, and > >continues to do so on every reboot for the next year (unless the user is > >advanced enough to know to manually run the script with the force flag) > > > >Other than races on startup, the normal case is that the system time will > >not go backwards unless it was intentionally changed (either by a user or > >by an update from an NTP server), so I don't believe it makes sense to > >reject such saves by default. (The protection for loads, on the other > >hand, is clearly needed.) > > > >For my specific use case, I simply reverted to the original behavior > >without any protection against saving, but I suppose the upstream solution > >would require an alternate solution to the race reported on #763589. > > Right. > > And in #763589 we have: > > >I've observed a system with a correctly working fake-hwclock > >(originally initalised by NTP) set its time back to shortly after the > >epoch, including in /etc/fake-hwclock.data. > > > >I believe this happened because "fake-hwclock save" was called after > >boot before "fake-hwclock load" was called. > > > >I think this happens in the case of a very early shutdown event that > >calls "/etc/init.d/rc 0" before "/etc/init.d/rcS" has completed. > > > >In my case, I have a Raspberry Pi rigged with an external shutdown > >signal hooked up via udev. If the signal is "high" at boot time, then > >the Pi shuts down without fully booting up. > > > >I'm not entirely sure that this is the cause, but the race is there. > > We have two conflicting requirements here, I think. Thanks for > explaining your logic, both of you. > > The problem is that I don't think there's a good solution to both > problems here. We can't *know* that the system time has been read from > fake-hwclock.data before calling "save". I briefly considered adding a > "I've seen this" flag that could be set in "load", but that's no > guarantee at all - if we power down unexpectedly then it'll be set > already at next boot. > > What we *can* do is instead add an extra declaration of system time > based on the build/release date of the particular version of the > fake-hwclock package in use, and refuse to back to a date before > *that* unless --force is used. How does that sound? > > Or can you think of any other possible fixes here? > > [ I've also just realised that I'll need to go back and re-add > initramfs support now that we automatically attempt to mount and > fsck /usr in the initramfs. Joy \o/ ] > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "I suspect most samba developers are already technically insane... Of > course, since many of them are Australians, you can't tell." -- Linus > Torvalds > > -- ............................................................................ *Roddy Shuler* | +1.585.530.7960 | Endless
