chromium: Startup fails due to helper binary permissions (on AMD64)
Launching the chromium-browser
binary in an Alpine Docker container results in the following error message:
The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/chromium/chrome-sandbox is owned by root and has mode 4755.
A possible workaround is to manually set the file mode to 4755.
Interestingly enough, this only occurs on AMD64 and not on ARM64, even though the permissions are the same there.
Given that it affects chromium in Docker on AMD64, it sounds somewhat similar to #14769, but the error pattern is completely different.
Environment
- Alpine 3.18.0
- chromium 113.0.5672.126-r0
- Privileged Docker container
Steps to reproduce
> docker run -it --privileged alpine
/ # apk --no-cache add chromium
# [...]
/ # adduser -D -g 'Test execution user,,,' executor # chromium must not be run as root
/ # su executor
/ $ chromium-browser --headless=new
[34:34:0517/114644.663795:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/chromium/chrome-sandbox is owned by root and has mode 4755.
[0517/114644.692964:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
[0517/114644.693173:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
[0517/114644.693601:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0517/114644.693617:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
Aborted
/ $ [43:43:0100/000000.758921:ERROR:zygote_linux.cc(661)] write: Broken pipe (32)
/ $ exit # Become root again
/ # chmod 4755 /usr/lib/chromium/chrome-sandbox
/ # su executor
/ $ chromium-browser --headless=new
Startup continues and ultimately fails (probably) due to wrong arguments, since it's apparently not supposed to be called that way. But the original issue is gone.