| Summary: | net-misc/ntp-4.2.8_p14-r1[caps] failes to start | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Klemen Mihevc <solor> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | candrews, petr.pisar, slyfox |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.ntp.org/show_bug.cgi?id=1433 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | ntp-4.2.8_p14-revert_caps_check.patch | ||
|
Description
Klemen Mihevc
2020-03-04 16:45:45 UTC
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(+) |
