[ntp:questions] NTP daemon broken in 2.6.19?
per at hedeland.org
Sat Dec 30 18:28:19 UTC 2006
<Pine.LNX.4.58.0612271629330.16319 at uranos.quantum.physik.uni-potsdam.de>
Timo Felbinger <Timo.Felbinger at physik.uni-potsdam.de> writes:
>On Sat, 23 Dec 2006, MH wrote:
>> Timo Felbinger wrote:
>> > On Sun, 17 Dec 2006, MH wrote:
>> >> I recently upgraded my kernel from 2.6.13 to 2.6.19 and discovered that
>> >> NTP service is no longer functional. The NTP daemon logs the following:
>> >> cap_set_proc() failed to drop root privileges: Operation not permitted
>> > Make sure you have the "default linux capabilities" in your new kernel,
>> > either as a module (modprobe capability), or just compile them statically
>> > into the kernel (somewhere under "security options" in the kernel config
>> > menu).
>> They were. Tried compiling them into the kernel as well. Same end result.
>> Weird thing is that NTPD actually synchronized successfully ONCE after the
>> new kernel was installed. It did not initially, nor has it since. Very odd.
>If it is really the cap_set_proc() call which fails and you are sure you
>start ntpd with root privileges initially, then maybe you need to recompile
>and reinstall libcap to make it work with the new kernel? (I dimly recall
>that I had to do this at some point).
>The library version seems to be not critical, both 1.10 and 1.92 work for
>me with various 2.6.x kernels.
It should probably be noted that the problem here is not just specific
to running ntpd on Linux, but to running the "Linux-modified" ntpd on
Linux - the reference implementation provided by ntp.isc.org doesn't
have the capability-dropping stuff that seems to be the problem (or at
least it didn't last time I looked).
That being said, I can't be bothered to hunt down the rpm or whatever to
find the "open" source for this version, but does it really fail fatally
if the capability-dropping doesn't work? It would seem to make more
sense to just continue running with root privileges in that case. Of
course, if ntpd isn't actually started with root privileges, it would
explain both the failure to drop privileges and the subsequent failure
to discipline the clock...
per at hedeland.org
More information about the questions