I've been scratching my head over this regression [1] for a while now, in the context of running a hirsute container on a 20.04 host (in particular, a GitHub workflow machine) In my case, the symptom is that after upgrading glibc, `which` is broken; that of course also uses faccessat(), similar to test -x.
I tried all sorts of the "usual" workarounds, as seccomp has been giving trouble for a while now [2]. But this failure is robust against fuse-overlayfs vs. vfs (inefficient full copies of the file system), root vs. user podman, podman vs. docker, and, relevant for this bug, it *also happens* with --security-opt=seccomp=unconfined and/org --privileged, both of which should disable seccomp.
Hence I believe this bug can't at least only be in libseccomp.
I've been scratching my head over this regression [1] for a while now, in the context of running a hirsute container on a 20.04 host (in particular, a GitHub workflow machine) In my case, the symptom is that after upgrading glibc, `which` is broken; that of course also uses faccessat(), similar to test -x.
I tried all sorts of the "usual" workarounds, as seccomp has been giving trouble for a while now [2]. But this failure is robust against fuse-overlayfs vs. vfs (inefficient full copies of the file system), root vs. user podman, podman vs. docker, and, relevant for this bug, it *also happens* with --security- opt=seccomp= unconfined and/org --privileged, both of which should disable seccomp.
Hence I believe this bug can't at least only be in libseccomp.
[1] https:/ /github. com/martinpitt/ umockdev/ runs/1984769591 ?check_ suite_focus= true#step: 3:1019 /bugzilla. redhat. com/show_ bug.cgi? id=1900021
[2] https:/