Since update today ntpd failes to start with: Mar 4 17:41:02 mih ntpd[6839]: ntpd 4.2.8p14@1.3728-o Wed Mar 4 16:37:37 UTC 2020 (1): Starting Mar 4 17:41:02 mih ntpd[6839]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u ntp:ntp Mar 4 17:41:02 mih ntpd[6839]: ---------------------------------------------------- Mar 4 17:41:02 mih ntpd[6839]: ntp-4 is maintained by Network Time Foundation, Mar 4 17:41:02 mih ntpd[6839]: Inc. (NTF), a non-profit 501(c)(3) public-benefit Mar 4 17:41:02 mih ntpd[6839]: corporation. Support and training for ntp-4 are Mar 4 17:41:02 mih ntpd[6839]: available at https://www.nwtime.org/support Mar 4 17:41:02 mih ntpd[6839]: ---------------------------------------------------- Mar 4 17:41:02 mih ntpd[6842]: proto: precision = 0.084 usec (-23) Mar 4 17:41:02 mih ntpd[6842]: basedate set to 2020-02-21 Mar 4 17:41:02 mih ntpd[6842]: gps base set to 2020-02-23 (week 2094) Mar 4 17:41:02 mih ntpd[6842]: Listen normally on 0 lo 127.0.0.1:123 Mar 4 17:41:02 mih ntpd[6842]: Listen normally on 1 wan 84.xxx.xxx.xxx:123 Mar 4 17:41:02 mih ntpd[6842]: Listen normally on 2 lan 10.0.0.1:123 Mar 4 17:41:02 mih ntpd[6842]: Listen normally on 3 lo [::1]:123 Mar 4 17:41:02 mih ntpd[6842]: Listen normally on 4 lan [2a01:260:xxxx:xxxx::1]:123 Mar 4 17:41:02 mih ntpd[6842]: Listening on routing socket on fd #21 for interface updates Mar 4 17:41:02 mih ntpd[6842]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Mar 4 17:41:02 mih ntpd[6842]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Mar 4 17:41:02 mih ntpd[6842]: cap_set_proc() failed to drop root privs: Operation not permitted Mar 4 17:41:02 mih ntpd[6839]: daemon child exited with code 255 if i roll back to 4.2.8_p13-r2 it works fine with same configs...
Same here with: net-misc/ntp-4.2.8_p14-r1::gentoo USE="caps readline threads vim-syntax -debug -ipv6 -libressl -openntpd -parse-clocks -samba (-selinux) -snmp -ssl -zeroconf" (~amd64) USE=-caps allows it to start. I tried with both libcap-2.32 and 2.33 since it was recently updated but that didn't help.
*** Bug 711534 has been marked as a duplicate of this bug. ***
Do you see similar behaviour? Two capset() calls where first succeeds and second fails. # LANG=C strace -f -etrace=clone,capset /usr/sbin/ntpd -p /tmp/ntpd.pid -g -u ntp:ntp clone(child_stack=0x7f453603ffb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[422557], tls=0x7f4536040700, child_tidptr=0x7f45360409d0) = 422557 strace: Process 422557 attached [pid 422557] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_TKILL, si_pid=422556, si_uid=0} --- [pid 422557] +++ exited with 0 +++ clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f4536041a10) = 422558 strace: Process 422558 attached [pid 422558] clone(child_stack=0x7f4536004fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTIDstrace: Process 422559 attached , parent_tid=[422559], tls=0x7f4536005700, child_tidptr=0x7f45360059d0) = 422559 [pid 422558] capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_CHROOT|1<<CAP_SYS_TIME, permitted=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_CHROOT|1<<CAP_SYS_TIME, inheritable=0}) = 0 [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=0} --- [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=0} --- [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=0} --- [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=0} --- [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=0} --- [pid 422559] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=422558, si_uid=123} --- [pid 422558] capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_BIND_SERVICE|1<<CAP_IPC_LOCK|1<<CAP_SYS_TIME, permitted=1<<CAP_NET_BIND_SERVICE|1<<CAP_IPC_LOCK|1<<CAP_SYS_TIME, inheritable=0}) = -1 EPERM (Operation not permitted) [pid 422559] ????( <unfinished ...> [pid 422559] +++ exited with 255 +++ [pid 422558] +++ exited with 255 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=422558, si_uid=123, si_status=255, si_utime=0, si_stime=0} --- +++ exited with 255 +++
The two capset() calls are fine. The first one with NULL second argument is to obtain a capability format for the second call. I think the problem is that ntpd first changes EUID and then it calls capset(): setuid(123) = 0 getpid() = 4619 tgkill(4619, 4621, SIGRT_1) = 0 setresuid(-1, 123, -1) = 0 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_BIND_SERVICE|1<<CAP_IPC_LOCK|1<<CAP_SYS_TIME, permitted=1<<CAP_NET_BIND_SERVICE|1<<CAP_IPC_LOCK|1<<CAP_SYS_TIME, inheritable=0}) = -1 EPERM A non-root user by default cannot obtain a CAP_NET_BIND_SERVICE capability. To do that, the ntpd executable would have to set a file capability which is not true: # getcap -v /usr/sbin/ntpd /usr/sbin/ntpd
This seems to be an issue introduced by upstream bug 1433 (see "See Also"). Reverting that patch "fixes" the issue. Now we need to find out if the upstream patch is at faul or if we just discovered another issue.
Created attachment 617174 [details, diff] ntp-4.2.8_p14-revert_caps_check.patch This reverts the change that introduced the issue. Please do NOT YET consider this a permanent fix. We might have just found another issue being revealed by the upstream change.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37dea0c5a7c3b80ed51400bd89b44268c959bbe2 commit 37dea0c5a7c3b80ed51400bd89b44268c959bbe2 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-03-05 18:50:28 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-03-05 18:51:00 +0000 net-misc/ntp: Revbump to fix ntpd startup with USE="caps" Closes: https://bugs.gentoo.org/711530 Package-Manager: Portage-2.3.92, Repoman-2.3.20 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> net-misc/ntp/files/ntp-4.2.8_p14-add_cap_ipc_lock.patch | 13 +++++++++++++ .../{ntp-4.2.8_p14-r1.ebuild => ntp-4.2.8_p14-r2.ebuild} | 1 + 2 files changed, 14 insertions(+)
