| 1 |
On Tue, 19 Jul 2016 21:23:16 +0300 |
| 2 |
Andrew Savchenko <bircoph@g.o> wrote: |
| 3 |
> On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@××××××××.org wrote: |
| 4 |
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote |
| 5 |
> > > |
| 6 |
> > > As I wrote earlier in this thread, ntp server is not a guarantee |
| 7 |
> > > that such problems will not happen. If hardware clocked was |
| 8 |
> > > significantly offset during boot, it may take several _hours_ for |
| 9 |
> > > ntp to fix this via clock skew. Apparantly commit may be made |
| 10 |
> > > during these several hours. |
| 11 |
> > |
| 12 |
> > I'm amazed that "robust linux servers" are deathly afraid of |
| 13 |
> > simply setting the time, and being done with it. And while we're at |
| 14 |
> > it, if a developer is doing development on a server machine, he may |
| 15 |
> > have other problems to worry about. At home I occasionally |
| 16 |
> > manually run a script that includes the 2 lines... |
| 17 |
> |
| 18 |
> I never said anything about "robust linux servers". If you think |
| 19 |
> than only servers need a gradual clock slew instead of stepping, |
| 20 |
> you are mistaken. |
| 21 |
> |
| 22 |
> > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org |
| 23 |
> > /usr/bin/sudo /sbin/hwclock --systohc |
| 24 |
> |
| 25 |
> And if time delta is significant, the system may become broken |
| 26 |
> this way. Congratulations. |
| 27 |
|
| 28 |
Really? I have many times skewed time by weeks using ntpdate with no |
| 29 |
issues. |
| 30 |
|
| 31 |
> The gradual NTP time slew was not invented because people were lazy |
| 32 |
> to run two simple commands. Actually it is just the opposite: |
| 33 |
> setting system time via a single huge step is much easier to |
| 34 |
> implement than a proper adjustment via a series of small time slews. |
| 35 |
> For servers it is indeed important in many ways, including |
| 36 |
> time stamp based cryptography as kerberos or database integrity. |
| 37 |
|
| 38 |
Sure randomly skewing time can cause weird issues, which is why it is a |
| 39 |
manual operation (and/or boot time operation). |
| 40 |
|
| 41 |
> |
| 42 |
> But desktops also do need a proper time adjustment: |
| 43 |
> - Filesystems will not operate correctly with time stamps in |
| 44 |
> future, in the best keys they will be marked/reported as needed a |
| 45 |
> repair procedure. |
| 46 |
|
| 47 |
I have only ever seen ext4 complain about the superblock timestamp, |
| 48 |
and fsck generally just corrects without issue, and it generally is |
| 49 |
only an issue after a reboot. |
| 50 |
|
| 51 |
> - Cron jobs may go broken too as chithanh mentioned already. |
| 52 |
|
| 53 |
Get a better crond? Decent cron daemons can detect time skews and act |
| 54 |
accordingly. |
| 55 |
|
| 56 |
> - Video encoding is not happy with time shifts at all. While small |
| 57 |
> predictable slews can be tolerated, large jumps will just broke the |
| 58 |
> process. |
| 59 |
|
| 60 |
Anything that cares about having a monotonic clock, and doesn't |
| 61 |
actually care about the real time (like video encoding) should just use |
| 62 |
the monotonic clock, not the system time. |
| 63 |
|
| 64 |
> - System may become *vulnerable* because of time stamp based attack. |
| 65 |
> Though it is not easy to use such behaviour, it is still possible. |
| 66 |
|
| 67 |
Once again, monotonic clock exists for a reason. If you want to |
| 68 |
talk about vulnerabilities, you do realize that doesn't work properly |
| 69 |
unless the client and server have reasonably similar system times. |
| 70 |
|
| 71 |
> - and many more... |
| 72 |
> |
| 73 |
> Best regards, |
| 74 |
> Andrew Savchenko |
Archives