Description of problem: There seems to be some changes in glibc between glibc-2.30.9000-16.fc32 and glibc-2.30.9000-17.fc32 and therefore adding additional capabilities is not enough for running chronyd in container Version-Release number of selected component (if applicable): sh$ rpm -q podman containers-common podman-1.6.2-2.fc31.x86_64 containers-common-0.1.40-3.fc31.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. dnf install -y podman 2. cat <<EOF FROM docker.io/fedora:rawhide RUN dnf install -y chrony && dnf update -y glibc EOF 3. podman build -t rawhide_chrony . 4. podman run --cap-add=SYS_TIME -ti --rm localhost/rawhide_chrony /usr/sbin/chronyd 5. echo $? Actual results: sh-5.0# podman run --cap-add=SYS_TIME -ti --rm localhost/rawhide_chrony /usr/sbin/chronyd adjtimex(0x8001) failed : Operation not permitted sh-5.0# echo $? 1 Expected results: sh-5.0# podman run --cap-add=SYS_TIME -ti --rm localhost/rawhide_chrony /usr/sbin/chronyd sh-5.0# echo $? 0 Additional info: Disabling seccomp helps as well sh-5.0# podman run --security-opt=seccomp=unconfined --cap-add=SYS_TIME -ti --rm localhost/rawhide_chrony /usr/sbin/chronyd sh-5.0# echo $? 0
It should be probably moved to skopeo because the file /usr/share/containers/seccomp.json is owned by that component. Adding glibc guys to CC sh-5.0# podman run --cap-add=SYS_TIME -ti --rm localhost/rawhide_chrony /usr/sbin/chronyd adjtimex(0x8001) failed : Operation not permitted sh-5.0# echo $? 1 sh-5.0# ausearch -m SECCOMP -i ---- type=SECCOMP msg=audit(11/13/2019 09:24:57.260:702) : auid=root uid=root gid=root ses=4 subj=system_u:system_r:container_t:s0:c27,c599 pid=33840 comm=chronyd exe=/usr/sbin/chronyd sig=SIG0 arch=x86_64 syscall=clock_adjtime compat=0 ip=0x7f49a273bdcb code=errno
It should be probably fixed also in older distributions because it is triggered by version of glibc in container and not host.
adjtimex is a legacy system call which is not implemented by all architectures, and there will be no Y2038 variant for 32-bit architectures. That's why we have switched to clock_adjtime in newer glibc versions.
It looks like the adjtimex syscall is allowed in Rawhide seccomp.json. Could you check /usr/share/containers/seccomp.json file?
This should also be blocked by SELinux.
(In reply to Daniel Walsh from comment #4) > It looks like the adjtimex syscall is allowed in Rawhide seccomp.json. Could > you check /usr/share/containers/seccomp.json file? It is not about adjtimex but about clock_adjtime I think it is obvious from the audit message in the comment1
Fixed in skopeo-0.1.41-2.dev.git24f4f82.fc32