Description of problem: If I run this in a container where seccomp denies ADDR_LIMIT_3G, it thinks it worked when it did not: [root@daf23c28d8db build]# setarch linux32 -B uname -m x86_64 This is because setarch is only checking for -EINVAL. If I run it without -B, it works as expected: [root@daf23c28d8db build]# setarch linux32 uname -m i686 Version-Release number of selected component (if applicable): util-linux-2.23.2-59.el7 How reproducible: 100% Steps to Reproduce: 1. create a container on a system where seccomp denies some personality(2) flags (podman or docker on fedora 29 will do this) 2. run setarch linux32 -B uname -m 3. see the wrong value Actual results: setarch execs the binary after personality(2) has returned failure Expected results: setarch shows an error
It seems we need upstream commits 9ed11cc260a28a64de0c1fa5d94d7cd6273781a5 and ae7065760d9bbe776a93a73d88e85c7796acb8cc.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1102