Bug 2030661
| Summary: | Universal Base Image 8 Minimal filesystem root permissions | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | jakub.rak <jakub.rak> |
| Component: | coreutils | Assignee: | Kamil Dudka <kdudka> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Frantisek Sumsal <fsumsal> |
| Severity: | high | Docs Contact: | Šárka Jana <sjanderk> |
| Priority: | unspecified | ||
| Version: | 8.5 | CC: | how981.tr, jose.gomez, kdudka, lkuprova, lmanasko, msekleta, sjanderk |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
.`coreutils` might report misleading EPERM error codes
GNU Core Utilities (`coreutils`) started using the `statx()` system call. If a `seccomp` filter returns an EPERM error code for unknown system calls, `coreutils` might consequently report misleading EPERM error codes because EPERM can not be distinguished from the actual _Operation not permitted_ error returned by a working `statx()` syscall.
To work around this problem, update the `seccomp` filter to either permit the `statx()` syscall, or to return an ENOSYS error code for syscalls it does not know.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-27 16:14:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jakub.rak@dynatrace.com
2021-12-09 12:25:06 UTC
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. Hello! To whomever it may concern... I believe this ticket or a new one shall be opened, because I reproduce a similar behavior under latest stable as of today Oct. 4th 2023. The issue can be reproduced when running UBI8 container on top of Centos on top of WSL 2. My stack is: -------------------------------------------------------------------------------- bash-4.4# uname -a && cat /etc/redhat-release && rpm -qa |grep coreutils-single Linux 93758255e78b 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.8 (Ootpa) coreutils-single-8.30-15.el8.x86_64 -------------------------------------------------------------------------------- Linux ENLUDEV04 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.6.1810 (Core) -------------------------------------------------------------------------------- Microsoft Windows [Version 10.0.22621.2283] -------------------------------------------------------------------------------- My Dockerfile: FROM registry.access.redhat.com/ubi8/httpd-24 USER root CMD bash Behavior: when running a shell (as root) bash-4.4# ls -lad . ls: cannot access '.': Operation not permitted bash-4.4# cd /usr/local/src/ && ls -l ls: cannot access 'mod_wsgi-4.9.4': Operation not permitted total 0 d????????? ? ? ? ? ? mod_wsgi-4.9.4 I'd like to try the workaround, but not familiar with (In reply to jose.gomez from comment #17) > Hello! > > To whomever it may concern... I believe this ticket or a new one shall be > opened, because I reproduce a similar behavior under latest stable as of > today Oct. 4th 2023. > > The issue can be reproduced when running UBI8 container on top of Centos on > top of WSL 2. > > My stack is: > > ----------------------------------------------------------------------------- > --- > bash-4.4# uname -a && cat /etc/redhat-release && rpm -qa |grep > coreutils-single > Linux 93758255e78b 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 > 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux release 8.8 (Ootpa) > coreutils-single-8.30-15.el8.x86_64 > ----------------------------------------------------------------------------- > --- > Linux ENLUDEV04 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 > UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > CentOS Linux release 7.6.1810 (Core) > ----------------------------------------------------------------------------- > --- > Microsoft Windows [Version 10.0.22621.2283] > ----------------------------------------------------------------------------- > --- > > My Dockerfile: > > FROM registry.access.redhat.com/ubi8/httpd-24 > USER root > CMD bash > > Behavior: when running a shell (as root) > > bash-4.4# ls -lad . > ls: cannot access '.': Operation not permitted > > bash-4.4# cd /usr/local/src/ && ls -l > ls: cannot access 'mod_wsgi-4.9.4': Operation not permitted > total 0 > d????????? ? ? ? ? ? mod_wsgi-4.9.4 > > > I'd like to try the workaround, but not familiar with Running the container with --security-opt seccomp=unconfined -> tested / it works normally! |