[
https://issues.apache.org/jira/browse/KUDU-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16003370#comment-16003370
]
Mike Percy commented on KUDU-2000:
----------------------------------
Some additional info:
After taking a look at the [glibc sources for
ntp_gettime|https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ntp_gettime.c;h=915b099dc570a4d5c1418f22b8e1c09b6eea5f86;hb=HEAD],
it appears that on Linux {{ntp_gettime()}} just calls {{adjtimex()}} with a
{{buf.modes == 0}}.
According to "man adjtimex":
{code}
ERRORS
EPERM buf.modes is neither 0 nor ADJ_OFFSET_SS_READ, and the caller
does not have sufficient privilege. Under Linux, the CAP_SYS_TIME capability
is required.
{code}
This seems a little ambiguous. Upon reading that, I initially thought that
{{buf.modes == 0}} should sufficient. But maybe the {{CAP_SYS_TIME}} capability
is always required on Linux no matter what.
If {{CAP_SYS_TIME}} is always required, that's a bit unfortunate because
according to {{man 7 capabilities}}, the {{CAP_SYS_TIME}} capability would
allow a privileged user in the container to set the system clock for any
containers on the system:
{code}
CAP_SYS_TIME
Set system clock (settimeofday(2), stime(2), adjtimex(2)); set
real-time (hardware) clock.
{code}
I wonder if this could be a Docker bug.
> Kudu requires CAP_SYS_TIME capability in Linux Docker containers
> ----------------------------------------------------------------
>
> Key: KUDU-2000
> URL: https://issues.apache.org/jira/browse/KUDU-2000
> Project: Kudu
> Issue Type: Bug
> Affects Versions: 1.3.1
> Reporter: Mike Percy
>
> When running Kudu in a Docker container, Kudu currently requires the
> CAP_SYS_TIME capability (or running the docker container with the
> --privileged flag).
> If run with default privileges, calling ntp_gettime() results in an EPERM
> error that apparently comes from adjtimex(). In that case, the resulting
> fatal error from HybridTime looks like the following in the logs:
> {code}
> F0508 22:36:35.687885 1 master_main.cc:68] Check failed: _s.ok() Bad
> status: Service unavailable: Cannot initialize clock: Error reading clock.
> ntp_gettime() failed: Operation not permitted
> *** Check failure stack trace: ***
> *** Aborted at 1494282995 (unix time) try "date -d @1494282995" if you are
> using GNU date ***
> PC: @ 0x7f6696f2c1d7 __GI_raise
> *** SIGABRT (@0x1) received by PID 1 (TID 0x7f66992a9940) from PID 1; stack
> trace: ***
> @ 0x7f6698c66370 (unknown)
> @ 0x7f6696f2c1d7 __GI_raise
> @ 0x7f6696f2d8c8 __GI_abort
> @ 0x1961719 (unknown)
> @ 0x843a9d google::LogMessage::Fail()
> @ 0x845a43 google::LogMessage::SendToLog()
> @ 0x8435f9 google::LogMessage::Flush()
> @ 0x8463cf google::LogMessageFatal::~LogMessageFatal()
> @ 0x7e9c23 (unknown)
> @ 0x7f6696f18b35 __libc_start_main
> @ 0x7e9629 (unknown)
> @ 0x0 (unknown)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
