Hide Forgot
Description of problem: Latest release of UBI 8 Minimal (8.5) has issue with privileges on filesystem root on unprivileged container running on RHEL Atomic 7.3.5 host. The issue is not observed with previous UBI 8 Minimal release (8.4). The issue is caused by coreutils-single-8.30-12.el8.x86_64 package, which on previous image version was coreutils-single-8.30-8.el8.x86_64. Version-Release number of selected component (if applicable): coreutils-single-8.30-12.el8.x86_64 Steps to Reproduce: docker run --entrypoint /bin/ls registry.access.redhat.com/ubi8/ubi-minimal:8.5 / Actual results: ls: cannot access '/': Operation not permitted Expected results: list of directories within root directory on container
Do you have any evidence that coreutils does anything wrong? There seem to be no related changes between -8 and -12: @@ -35,6 +35,24 @@ Patch6: coreutils-8.31-sums-man-pages.patch # df --local: recognize afs, auristorfs, and smb3 as remote fs (#1798030) Patch7: coreutils-8.30-df-local-fs.patch +# use statx instead of stat when available (#1760300) +Patch8: coreutils-8.30-statx.patch + +# rm: do not skip files upon failure to remove an empty dir (#1905481) +Patch9: coreutils-8.32-rm-stray-skip.patch + +# split: fix --number=K/N to output correct part of file (#1921246) +Patch10: coreutils-8.32-split-number.patch + +# mountlist: recognize fuse.portal as dummy file system (#1952714) +Patch11: coreutils-8.32-fuse-portal.patch + +# tail: fix stack out-of-bounds write with --follow (#1974784) +Patch12: coreutils-8.30-tail-use-poll.patch + +# df: fix duplicated remote entries due to bind mounts (#1962515) +Patch17: coreutils-8.32-df-duplicated-entries.patch + # disable the test-lock gnulib test prone to deadlock Patch100: coreutils-8.26-test-lock.patch
(In reply to Kamil Dudka from comment #1) > +# use statx instead of stat when available (#1760300) > +Patch8: coreutils-8.30-statx.patch Actually, the statx() syscall might be blocked by the seccomp filter that you are using, returning EPERM by mistake. This needs to be fixed in the seccomp filter instead. See bug #1900021 where a different syscall caused a similar issue.
Looks like seccomp indeed is the issue here - there is no more permission error when I run container with --security-opt seccomp=unconfined. I upgraded libseccomp on the host as suggested here https://github.com/docker/for-linux/issues/208#issuecomment-442978983 and it helped. Not sure if docker upgrade is needed as well since I'm using RHEL Atomic and had to upgrade all at once. Relevant package upgrades: docker 2:1.12.6-28.git1398f24.el7 -> 2:1.13.1-208.git7d71120.el7_9 libseccomp 2.3.1-2.el7 -> 2.3.1-4.el7
Perfect, thanks for confirmation! I think we should document this as known issue.
Hi @kdudka could you please review the text for this known issue: https://docs.google.com/document/d/10UJ0GH48IXidlcDOR3ezQoeojDwEE9IUelzY5OfxDOc/edit Thank you very much for your cooperation. SJ
Thanks! It looks perfect to me from technical point of view. One minor suggestion inline.
Known issue published: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.5_release_notes/known-issues#BZ-2030661
Nice. Thanks to all involved!
I have one more question: It works when I upgraded libseccomp 2.3.1-2.el7 -> 2.3.1-4.el7 on RH7.6/7.7 but not work on RH7.4 host, is there anything else needed to do besides updating libseccomp on RHEL7.4 host?
(In reply to HowWang from comment #13) > I have one more question: It works when I upgraded libseccomp 2.3.1-2.el7 -> > 2.3.1-4.el7 on RH7.6/7.7 but not work on RH7.4 host, is there anything else > needed to do besides updating libseccomp on RHEL7.4 host? it is also needed to upgraded docker version: docker-1.13.1-74 -> docker-1.13.1-209 + libseccomp 2.3.1-2.el7 -> 2.3.1-4.el7 it works to run ubi8 container on RH7.4 host without reporting misleading EPERM error.