0

I'm playing with containerizing various parts of my server infrastructure and one of the services I would like to run in container is ntp daemon.

I'm using systemd-nspawn (systemd 233) as a hypervisor as well as init process inside of the containers.

ntpd version is 4.2.8p10.

Every time I try to start ntpd inside of a container it crashes with cap_set_proc() operation not permitted error:

21 Oct 11:10:23 ntpd[51]: ntpd [email protected] Fri Oct 20 23:28:39 UTC 2017 (1): Starting
21 Oct 11:10:23 ntpd[51]: Command line: ntpd -g -n -u ntp:ntp
21 Oct 11:10:23 ntpd[51]: Cannot set RLIMIT_MEMLOCK: Operation not permitted
21 Oct 11:10:23 ntpd[51]: proto: precision = 0.335 usec (-21)
21 Oct 11:10:23 ntpd[51]: Listen normally on 0 v4wildcard 0.0.0.0:123
21 Oct 11:10:23 ntpd[51]: Listen normally on 1 lo 127.0.0.1:123
21 Oct 11:10:23 ntpd[51]: Listening on routing socket on fd #18 for interface updates
21 Oct 11:10:23 ntpd[51]: mlockall(): Cannot allocate memory
21 Oct 11:10:23 ntpd[51]: start_kern_loop: ntp_loopfilter.c line 1119: ntp_adjtime: Operation not permitted
21 Oct 11:10:23 ntpd[51]: set_freq: ntp_loopfilter.c line 1082: ntp_adjtime: Operation not permitted
21 Oct 11:10:23 ntpd[51]: cap_set_proc() failed to drop root privs: Operation not permitted

What I have tried so far:

  1. Building ntpd without capabilities enabled - it starts properly, but still has same ntp_adjtime syscall permission issues.
  2. Running systemd-nspawn with --private-users=0 and without --private-users at all.
  3. Playing with capabilities for systemd-nspawn itself (mainly CAP_SYS_TIME and CAP_NET_BIND_SERVICE)
  4. Playing with capabilities for ntpd inside of the container.

All this gave no positive results and I wonder what am I missing. Any ideas will be greatly appreciated.

Improve this question
4
  • you don't set capabilities on systemd-nspawn. You use the capability option of systemd-nspawn. Commented Oct 21, 2017 at 8:38
  • @sourcejedi I have tried adding both capabilities required by ntpd into systemd-nspawn service itself. Commented Oct 22, 2017 at 21:08
  • that's also the wrong way to describe what you want to do. The systemd-nspawn command drops capabilities, according to the option you pass it. You cannot increase capabilities by setting them on systemd-nspawn.service. Commented Oct 23, 2017 at 7:21
  • I see what you mean, and I think I explained it wrong. What I tried is setting capability on the service file for systemd-nspawn on host, passing same capability as --capability argument to systemd-nspawn in the host and setting this capability on ntpd service inside of the container. Hope that makes sense. Commented Oct 23, 2017 at 9:33

1 Answer 1

Reset to default
0

Wow, surprised this hasn't been answered after 7 years

I used the --capability flag from the command line for chronyd, a requirement for samba-ad-dc.service on a domain controller I'm setting up inside of a Debian 12 systemd-container.

Example:

#!/bin/sh
CONTAINER_PATH='/var/lib/machines/domaincontroller'
CHRONYD_REQUIREMENT='CAP_SYS_TIME'

sudo systemd-nspawn -b \
    --capability="${CHRONYD_REQUIREMENT}" \
    --directory="${CONTAINER_PATH}" &
Improve this answer
1
  • You are not using private users though. To my knowledge, it is still impossible to achieve capabilities support with private users to this day. Commented Oct 28, 2024 at 23:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.