NTP Error - "Failed to drop root privileges."
I encountered an issue after installing NTP on a VM running CentOS 5.5. (I installed it using the standard "yum install ntp".) When I attempted to start NTP, it would fail to sync with the NTP servers, but seemed to start ok. If I checked its status, though, I would see that there was a dead PID file in /var/run, and that it wasn't actually running.
Checking the /var/log/messages file, I would see this each time I attempted to start it.
Jun 5 03:46:25 cent01 ntpdate: cap_set_proc failed.
Jun 5 03:46:25 cent01 ntpd: ntpd email@example.com Sat Dec 19 00:56:13 UTC 2009 (1)
Jun 5 03:46:25 cent01 ntpd: precision = 1.000 usec
Jun 5 03:46:25 cent01 ntpd: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface wildcard, ::#123 Disabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface lo, ::1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface lo, 127.0.0.1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface venet0, 127.0.0.1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface venet0:0, [MY SERVER IP]#123 Enabled
Jun 5 03:46:25 cent01 ntpd: kernel time sync status 0040
Jun 5 03:46:26 cent01 ntpd: cap_set_proc() failed to drop root privileges: Operation not permitted
I did some Googling, and tried a couple of things.
- Uninstalled and reinstalled ntpd.
- Updated the libcap package.
- Temporarily disabled iptables. Verified nothing was blocking port 123.
- Verified connectivity to NTP servers.
I eventually ran across a post that alluded to the /etc/sysconfig/ntpd file, one that I hadn't touched yet. Taking a look at that, I saw this at the top.
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
This seemed to match the error I was seeing in the messages file. For grins, I commented this line out and attempted to start NTP. It sycned and fired right up. The resulting PID file is also owned by root, as would be expected as a result of commenting out that line.
My question is this. I feel like my workaround is sort of a band-aid, and probably not the most secure solution. This is a personal server, so if something happens to it, it's not really a huge deal. For my own understanding, though, I'd like to get a better understanding of this, and see if anyone has encountered this issue before, or has a better solution. Various articles and threads I have read allude to various "kernel bugs" and things of this nature, but nothing specific is ever mentioned.
Here are the relevant stats.
[root@cent01 run]# cat /etc/redhat-release
CentOS release 5.5 (Final)
[root@cent01 run]# uname -a
Linux cent01.xxxxxxxxx.net 2.6.18-028stab068.9 #1 SMP Tue Mar 30 17:22:31 MSD 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@cent01 run]# rpm -qa | grep ntp
[root@cent01 run]# grep ntp /etc/passwd
If anyone has any thoughts, or has seen this before, your feedback would be most appreciated. :)
[root@cent01 run]2.6.18-028stab068.9 #1 SMP[/QUOTE]
That looks like a non-standard kernel to me. To drop root privileges your kernel needs to be compiled with POSIX Capabilities enabled. If it's an external module you should load it before starting the NTPd.
Yes, it was.
Ok, This is a great thread that allowed me to get NTP running on my new "CentOS release 5.5 (Final)"
I edited out the line in: /etc/sysconfig/ntpd Now I started ntpd and it stays running.
I went to an older server "CentOS release 4.8 (Final)" and had to do the same fix to keep ntpd running.
The 5.5 release was new out of the box... so the 4.8 has been running a good while so I don't consider
it a non standard installation. I do want to be secure and not run ntpd as root if it is a security issue.
I did a simple yum install ntp version 4.2.2p1 on the Centos5.5
and ntp 4.2.0.a.20040617 on Centos 4.8
Any other suggestions to make this work without the hack of sysconfig ?
Clocks in VMs are subtle; I vaguely recall that it is better not to run NTP in guests and to rely on the NTP-synchronised host's clock. This excerpt from the VirtualBox Manual alludes to some of the issues which presumably apply to all virtualisation products:
|All times are GMT -5. The time now is 12:09 AM.|