Description of problem: This is happening in a bit unusual environment -- a Fedora 34 container running in a docker container on a CentOS 7 host. I'm aware that docker is not a preferred container runtime, yet it feels correct to report in order to avoid a similar issue in a more usual environment. Still, having builtin `test` and `/usr/bin/test` returning different exit code feels wrong a lot, no matter what kernel or container technology is between. Version-Release number of selected component (if applicable): # uname -a Linux ebd84cea420e 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # rpm -q bash bash-5.1.0-1.fc34.x86_64 How reproducible: well in the described environment Steps to Reproduce: First, on a CentOS 7 host: [root@centos7 /]# yum install -y docker [root@centos7 /]# service docker start [root@centos7 /]# docker pull registry.fedoraproject.org/fedora:34 [root@centos7 /]# docker run -ti --rm registry.fedoraproject.org/fedora:34 bash Then, in the F34 container: [root@ed5c14317c6f /]# yum -y install mariadb-server [root@ed5c14317c6f /]# test -x /usr/bin/my_print_defaults [root@ed5c14317c6f /]# echo $? 1 [root@ed5c14317c6f /]# /usr/bin/test -x /usr/bin/my_print_defaults [root@ed5c14317c6f /]# echo $? 0 [root@ed5c14317c6f /]# type test test is a shell builtin Actual results: Builtin `test` returns different result (exit code) than `/usr/bin/test`. `/usr/bin/test` is correct. Expected results: The exit code should be the same. Additional info: I'd love to debug more, but don't know how to debug builtin.
*** This bug has been marked as a duplicate of bug 1900021 ***
Thank you for reporting the bug! This is a known issue, unfortunately.
I forgot to say that there is also a RHEL-7 bug for libseccomp, which is most likely the culprit in this case: bug #1908281
(In reply to Kamil Dudka from comment #3) > I forgot to say that there is also a RHEL-7 bug for libseccomp, which is > most likely the culprit in this case: > > bug #1908281 It is very probable, as with --privileged option it works. Anyway, just to share what I see, just in case it's helpful.. It seems to be reproducible with podman as well actually, but it works fine with F33, so the matrix looks like this: F33 on CentOS 7 (works): # podman run -ti --rm registry.fedoraproject.org/fedora:33 bash -c 'yum -y install mariadb-server &>/dev/null ; test -x /usr/bin/my_print_defaults ; echo $? ; /usr/bin/test -x /usr/bin/my_print_defaults ; echo $?' 0 0 # docker run -ti --rm registry.fedoraproject.org/fedora:33 bash -c 'yum -y install mariadb-server &>/dev/null ; test -x /usr/bin/my_print_defaults ; echo $? ; /usr/bin/test -x /usr/bin/my_print_defaults ; echo $?' 0 0 F34 on CentOS 7 (does not work): # podman run -ti --rm registry.fedoraproject.org/fedora:34 bash -c 'yum -y install mariadb-server &>/dev/null ; test -x /usr/bin/my_print_defaults ; echo $? ; /usr/bin/test -x /usr/bin/my_print_defaults ; echo $?' 1 0 # docker run -ti --rm registry.fedoraproject.org/fedora:34 bash -c 'yum -y install mariadb-server &>/dev/null ; test -x /usr/bin/my_print_defaults ; echo $? ; /usr/bin/test -x /usr/bin/my_print_defaults ; echo $?' 1 0 But will follow #1908281 further.
(In reply to Honza Horak from comment #4) > F33 on CentOS 7 (works): This is expected because F33 glibc does not use the faccessat2() syscall. Use of the syscall was (re)introduced in glibc-2.32.9000-16.fc34 per bug #1869030.