Xenial Kernel Does Not Appear to Have Sandbox Capabilities

When we are running our tests using chrome headless and chrome is reporting:

No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

We actually use Travis-CI to run our docker images which tests everything for us. The build that is failing is: https://travis-ci.com/rgpm/core/builds/131064462. The last successful run on Travis-CI was: https://travis-ci.com/rgpm/core/builds/130139458.

The main change that I could find was that the successful build was on Trusty, while the newer build was on Xenial. It appears that the Xenial image is missing something that the Trusty image contained.

Is this a feature or a bug? I would like to not limit our containers to Trusty as the containers are designed to run on any system. I would say that the container runs fine on my system but I know that isn’t too useful for everyone else. I can tell that the Xenial/Trusty switch happened within the past 6 days for us.

According to https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#running-puppeteer-in-docker, you need to run docker with --cap-add=SYS_ADMIN to run Puppeteer in a container.

As per http://man7.org/linux/man-pages/man7/capabilities.7.html and https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#recommended-enable-user-namespace-cloning, this is needed to use unshare inside the container that Chrome needs for its sandboxing feature.

I don’t know which exact change triggered the fail – but, as you can see, it’s actually an error that this was working before! https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md refers to a ticket that all but disabled the use of suid sandbox in Chrome in favor of the namespace one but it’s from 2016.

Thanks for the hint. I should have known because our makefile uses the capability, but I didn’t even think about it. I also fixed the .travis file so that it uses the makefile this time. That should have been done originally, but I’m new to Travis CI.

Thanks for the help! Figures it was an error that it was working originally.