Mitigating Docker Build Issues on Older glibc Hosts

When running newer operating systems as Docker containers on older host systems—such as Ubuntu 20.04 or CentOS 7—a compatibility issue arises due to a new glibc call (clone3) not translating correctly to the older glibc (<=2.34) of the host system, resulting in the call being incorrectly translated, and blocked.

One workaround to this issue involves temporarily disabling security measures by utilizing the following flag:

--security-opt seccomp=unconfined

However, this workaround is ineffective with the ‘docker build’ command, preventing users from specifying unconfined security contexts.

This bug is particularly noticeable in GitHub Actions and can be traced directly to code changes within Docker (moby). While newer versions of Docker are expected to resolve this issue, it may take some time for these changes to be backported to the available distribution packages.

To address this, the security context and policy can be disabled entirely for all Docker operations. However, this significantly reduces security and may leave regular Docker containers vulnerable to malicious system calls. This solution is not recommended for systems running anything more critical than a build server. For build servers where reduced security is acceptable, the following steps can be taken to enable ‘docker build’ operations of newer OS on an older Docker host.

Modify Docker Configuration

Edit or create the file /etc/docker/daemon.json with the following content:

{
  "seccomp-profile": "/etc/docker/seccom.json"
}

Define Seccomp Policy

Create the file /etc/docker/seccom.json containing the following policy:

{
    "defaultAction": "SCMP_ACT_ALLOW",
    "syscalls": [
    ]
}

Restart Docker Daemon

After making these changes, restart the Docker daemon. Note that Docker-ce may have specific requirements with its systemd unit file, potentially necessitating a brief delay before restarting Docker. Use the following command to ensure a seamless restart:

systemctl stop docker ; sleep 5 ; systemctl start docker || systemctl clean docker && systemctl start docker

This sequence guarantees that systemd will attempt to start Docker successfully.

Final Considerations:

• These settings should never be applied to systems where Docker containers provide services to potential attackers, as they compromise the entire Docker environment’s security.
• To revert these changes, simply restore the file /etc/docker/daemon.json to its previous state. If it did not exist before, rename your file to .old or .bak, then restart the Docker service.

By following these steps, users can address compatibility issues when running Docker builds on older glibc hosts, albeit at the expense of reduced security.