You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: mount procfs in chroot for Java/dotnet runtime support (#556)
* fix: mount procfs in chroot for Java/dotnet runtime support
The static bind mount of /proc/self always resolved to the parent shell's
executable, causing .NET CLR to fail with "Cannot execute dotnet when renamed
to bash" and preventing proper /proc/cpuinfo access needed by the JVM.
Replace the static /proc/self bind mount with a fresh container-scoped procfs
mounted at /host/proc via 'mount -t proc'. This provides dynamic /proc/self/exe
resolution per-process while only exposing container processes (not host).
Changes:
- Mount procfs in entrypoint.sh before chroot (requires SYS_ADMIN capability)
- Add SYS_ADMIN to container cap_add, dropped via capsh before user code
- Add apparmor:unconfined in chroot mode (Docker's default blocks mount)
- Remove mount/umount from seccomp blocklist (safe: SYS_ADMIN dropped)
- Add DOTNET_ROOT passthrough for .NET runtime path resolution
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: harden procfs mount and keep umount blocked in seccomp
- Mount procfs with nosuid,nodev,noexec options for defense-in-depth
- Fail fast (exit 1) on mount failure instead of warning, since Java/.NET
runtimes will fail with confusing errors without /proc/self/exe
- Add umount and umount2 back to seccomp blocked list since only mount
(not unmount) is needed for the procfs setup
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0 commit comments