Lockfile generation fails in Docker containers

[maxrake]

Lockfile generation fails in Docker containers

[kylewillmon]

Docker heavily restricts the unshare syscall which is required for Birdcage to function.

If you have control over the execution of the container, you can try modifying the docker run command to make it work. It might just need --cap-add=CAP_SYS_ADMIN, but the docs are a bit unclear on user namespaces and I have not tested that... Alternately, you could use a custom seccomp filter with --security-opt="seccomp=profile.json" or even disable the seccomp filter entirely with --security-opt="seccomp=unconfined"

Ultimately, this is the reason that we included a --skip-sanbox option in 732b0d3. When docker is in use, further sandboxing is impractical and potentially unnecessary.

[maxrake]

Knowing when to skip using the sandbox (at runtime) can be done in several ways:

• Check for when Docker is in use
  • PRO: easy, by checking for the existence of a /.dockerenv file
  • CON: disabling use of the sandbox is possible by creating that file
  • CON: Docker may not be the only environment where the sandbox does not work
• Attempt to use the sandbox for something that should always succeed
  • PRO: can be used for any environment and will survive implementation changes to both Phylum and Docker
  • CON: it may still be possible to manipulate the environment to cause a failure and thus control the use of the sandbox

Discussion with the team on 28 NOV 2023 resulted in the decision to go with the second option. In particular, the command to use was determined to be:

phylum sandbox --allow-run / true

If that command fails, then it must be due to the environment not playing well with the Birdcage sandbox. Only then should the use of the sandbox be skipped.