Hi, Am Donnerstag, 18. Februar 2021, 12:31:48 CET schrieb Ladislav Slezak:
Dne 17. 02. 21 v 15:27 Thorsten Kukuk napsal(a):
On Wed, Feb 17, Cristian Rodríguez wrote:
We have better mechanisms now, including extensive sandboxing and namespaces support configurable via systemd unit drop-ins.
And especially for postfix we even have a container :) That's with glibc 2.33 and lmdb working fine without the need for an additional chroot environment.
Actually the newer glibc makes troubles also in containers. We are getting a lot of EPERM erros in TW Docker images running as GitHub Actions.
See https://github.com/yast/yast-ntp-client/pull/166/checks?check_run_id=1922192... or https://github.com/yast/yast-samba-server/runs/1922239238#step:5:153
It seems that the new glibc requires a newer kernel, a similar issue was also reported for WSL: https://github.com/microsoft/WSL/issues/6562
The issue is that old docker/podman block faccessat2 with -EPERM instead of letting -ENOSYS through. Some links: https://github.com/seccomp/libseccomp/issues/314 https://github.com/opencontainers/runc/pull/2750
There is a patch for Docker (see https://docs.docker.com/engine/release-notes/#security-1) but that means you need Docker >= 20.10.0 which might not be available for all systems or you might not be able to upgrade the Docker host like in the containerized GitHub Actions ... :-(
Even upgrading won't work in all cases, for instance the latest docker version for ubuntu is apparently still affected. The only workaround is to disable seccomp altogether, with "--security-opt seccomp:unconfined". Due to the nature of the bug there's no workaround on our side possible, other than disabling use of faccessat2 in glibc completely. On 32bit platforms some other syscalls like futex_time64 might also be affected. Cheers, Fabian