It seems obvious to me that ntpd should log an error and terminate=20r=20
when it is unable to adjust the system clock.=C2=A0 To my surprise,=20 https://bugs.ntp.org/1433 pointed out that when a Linux ntpd binary=20
built to use capabilities is run on a kernel build without capability=20 capability, ntpd blithely runs without complaint while effectively=20
doing nothing.=C2=A0 For this specific problem, you could blame the use=
and say they need to use ntpd built --without-linux-caps, but there's=20ties=20
a more general issue of ntpd not reporting let alone aborting on a=20
failure to control the clock.
To explain the context a bit, I came across bug 1433 somehow and saw=20
that in 2019 the decade-old bug was fixed by having ntpd test for=20
whether capabilities work before dropping root (they're needed to=20
crank the clock when not running as root on Linux).=C2=A0 When capabili=
do not work, ntpd was then ignoring the request to drop root and run=20an=20
as a user, typically "ntp".=C2=A0 This meant it was silently opening up=
opportunity for more useful privilege elevation or remote code=20or=20
execution despite the user's explicit configuration, and that's=20 unacceptable to me.=C2=A0 My intention is to change the behavior to err=
out when controlling the clock fails (via step or slew).=C2=A0 If you t=hink=20
that's a bad idea, please speak up and explain your reasoning.I agree, that seems like The Right Thing to do.
Cheers,
Dave Hart
On Tue, Nov 12, 2024 at 07:10:12PM +0000, Dave Hart wrote:e
It seems obvious to me that ntpd should log an error and terminate whenit
is unable to adjust the system clock. To my surprise, https://bugs.ntp.org/1433 pointed out that when a Linux ntpd binarybuilt
to use capabilities is run on a kernel build without capabilitycapability,
ntpd blithely runs without complaint while effectively doing nothing.For
this specific problem, you could blame the user and say they need to us=
pdntpd built --without-linux-caps, but there's a more general issue of nt=
not reporting let alone aborting on a failure to control the clock.
Note that widely used operating systems, like Apple's OS X, run
ntpd as a monitoring service that explicitly does not/cannot discipline
the clock.
I've also heard of people explicitly running ntpd to monitor and
log statistics, without wanting it to discipline the clock.
Perhaps the cleanest way to do this is add a flag to run the
daemon without attempting to discipline the clock?
It seems obvious to me that ntpd should log an error and terminate when it
is unable to adjust the system clock. To my surprise, https://bugs.ntp.org/1433 pointed out that when a Linux ntpd binary built
to use capabilities is run on a kernel build without capability capability, ntpd blithely runs without complaint while effectively doing nothing. For this specific problem, you could blame the user and say they need to use
ntpd built --without-linux-caps, but there's a more general issue of ntpd
not reporting let alone aborting on a failure to control the clock.
On Thu, Nov 14, 2024 at 2:31rC>AM Majdi S. Abbas <msa@latt.net <mailto:msa@latt.net>> wrote:
On Tue, Nov 12, 2024 at 07:10:12PM +0000, Dave Hart wrote:
> It seems obvious to me that ntpd should log an error and
terminate when it
> is unable to adjust the system clock.-a To my surprise,
> https://bugs.ntp.org/1433 <https://bugs.ntp.org/1433> pointed out
that when a Linux ntpd binary built
> to use capabilities is run on a kernel build without capability
capability,
> ntpd blithely runs without complaint while effectively doing
nothing.-a For
> this specific problem, you could blame the user and say they need
to use
> ntpd built --without-linux-caps, but there's a more general issue
of ntpd
> not reporting let alone aborting on a failure to control the clock.
-a -a -a -a Note that widely used operating systems, like Apple's OS X, run
ntpd as a monitoring service that explicitly does not/cannot discipline
the clock.
-a -a -a -a I've also heard of people explicitly running ntpd to
monitor and
log statistics, without wanting it to discipline the clock.
-a -a -a -a Perhaps the cleanest way to do this is add a flag to run the
daemon without attempting to discipline the clock?
I believe that flag is already there, "disable ntp".-a I haven't used it though.
Cheers,
Dave Hart
To be clear, deciding when ntpd should abort if it cannot discipline the clock should be done at the "right" place in the code - not too early,
and not too late.
On Thu, Nov 14, 2024 at 7:04rC>AM Harlan Stenn <stenn@nwtime.org> wrote:
To be clear, deciding when ntpd should abort if it cannot
discipline the
clock should be done at the "right" place in the code - not too
early,
and not too late.
Well, Goldilocks, it seems obvious to me -- when an attempt to modify
the system time/clock rate fails.
Cheers,
Dave Hart
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:48:42 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,321 |