Bug 1772053

Summary:	chronyd cannot run with the CAP_SYS_TIME with podman
Product:	[Fedora] Fedora	Reporter:	Lukas Slebodnik <lslebodn>
Component:	skopeo	Assignee:	Lokesh Mandvekar <lsm5>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	amurdaca, bbaude, debarshir, dwalsh, frantisek.kluknavsky, fweimer, jnovy, lsm5, mheon, nalin, rh.container.bot, santiago
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-19 12:24:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lukas Slebodnik 2019-11-13 14:24:35 UTC

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

Comment 1 Lukas Slebodnik 2019-11-13 14:26:55 UTC

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

Comment 2 Lukas Slebodnik 2019-11-13 14:30:03 UTC

It should be probably fixed also in older distributions because it is triggered by version of glibc in container and not host.

Comment 3 Florian Weimer 2019-11-13 14:32:50 UTC

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.

Comment 4 Daniel Walsh 2019-11-16 16:19:25 UTC

It looks like the adjtimex syscall is allowed in Rawhide seccomp.json. Could you check /usr/share/containers/seccomp.json file?

Comment 5 Daniel Walsh 2019-11-16 16:19:45 UTC

This should also be blocked by SELinux.

Comment 6 Lukas Slebodnik 2019-11-18 14:03:21 UTC

(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

Comment 7 Daniel Walsh 2019-11-19 12:24:27 UTC

Fixed in skopeo-0.1.41-2.dev.git24f4f82.fc32