Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: Chrome fails to start due to incorrect default chrome-sandbox permissions #8836

Closed
pimterry opened this Issue Nov 30, 2017 · 54 comments

Comments

Projects
None yet
@pimterry
Copy link

pimterry commented Nov 30, 2017

See https://travis-ci.org/pimterry/mockttp/jobs/309509522 for an example.

Chrome fails to start in my tests, using the Chrome addon and running XVFB, with:

Cannot start Chrome
[4315:4315:1130/133541.781662:FATAL:setuid_sandbox_host.cc(157)] 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 /opt/google/chrome/chrome-sandbox is owned
by root and has mode 4755.

My config is very simple, but in case it's interesting:

language: node_js
node_js:
    - 'node'
    - '8'
    - '7'
    - '6'
before_script:
    - "export DISPLAY=:99.0"
    - "sh -e /etc/init.d/xvfb start"
    - sleep 3 # give xvfb some time to start
addons:
    chrome: stable

I'm going to try to work around this by moving to sudo, and manually changing the chrome-sandbox owner and permissions, but it seems like this should work by default.

@pimterry

This comment has been minimized.

Copy link
Author

pimterry commented Nov 30, 2017

Furthermore, I can confirm this is a regression in Travis itself (either the OS setup, or the Chrome version used has changed). This build passed a month ago:

This push of exactly the same commit on a new branch today fails with the error above:

@pimterry pimterry changed the title Chrome fails to start due to incorrect default chrome-sandbox permissions Regression: Chrome fails to start due to incorrect default chrome-sandbox permissions Nov 30, 2017

pimterry added a commit to httptoolkit/mockttp that referenced this issue Nov 30, 2017

@AviVahl

This comment has been minimized.

Copy link

AviVahl commented Nov 30, 2017

pimterry added a commit to httptoolkit/mockttp that referenced this issue Nov 30, 2017

@pimterry

This comment has been minimized.

Copy link
Author

pimterry commented Nov 30, 2017

As a workaround httptoolkit/mockttp@852849f has fixed it for me: use sudo: required, chown & chmod chrome-sandbox to have the correct permissions, and everything starts up correctly.

@rwwagner90

This comment has been minimized.

Copy link

rwwagner90 commented Nov 30, 2017

Nice workaround @pimterry! I just noticed this regression on all my travis jobs this morning as well. Any official fixes coming or should we add that workaround?

@sebworks sebworks referenced this issue Nov 30, 2017

Merged

Fix for chrome bug on Travis #3624

0 of 11 tasks complete
@cotsog

This comment has been minimized.

Copy link
Member

cotsog commented Nov 30, 2017

Hey everyone,

We are still looking into the contributing factors for this issue.

Apart from @pimterry's fix, could someone confirm if just adding the following to your .travis.yml file also work?

addons:
  chrome: stable

Edit: Based on the comments below, this ☝️ alone doesn't work. Please either use @pimterry's suggestion or the following:

sudo: required
addons:
  chrome: stable

Thanks!

@Turbo87

This comment has been minimized.

Copy link

Turbo87 commented Nov 30, 2017

@cotsog that is what we have in https://github.com/emberjs/ember-test-helpers/blob/ca52448c55f510551389853d6188150a7f0a0ece/.travis.yml#L9-L10 and it still seems to fail.

also we're not using xvfb, but using the --headless mode with sudo: false instead, but are experiencing the same issues.

@pimterry

This comment has been minimized.

Copy link
Author

pimterry commented Nov 30, 2017

@cotsog My fix is to a travis file that already contains that addons line. On its own, that doesn't work.

@cotsog

This comment has been minimized.

Copy link
Member

cotsog commented Nov 30, 2017

@Turbo87, @pimterry: thanks for the confirmation. I've updated my comment above to include the current working workaround i.e.

Please either use @pimterry's suggestion or the following:

sudo: required
addons:
 chrome: stable

Thank you for your patience!

@XhmikosR

This comment has been minimized.

Copy link

XhmikosR commented Nov 30, 2017

@cotsog: please update this issue when the problem is solved so that we know to revert the workaround, thanks!

sloria added a commit to CenterForOpenScience/osf.io that referenced this issue Nov 30, 2017

Disable karma tests until travis-ci/travis-ci#8836 is resolved
Using the workaround in the travis-ci/travis-ci#8836 is not
feasible for us because our tests would take much longer than
they already do.

Will re-enable when the travis issue is resolved :crossed-fingers:

sloria added a commit to CenterForOpenScience/osf.io that referenced this issue Nov 30, 2017

@cespinoza-loga

This comment has been minimized.

Copy link

cespinoza-loga commented Nov 30, 2017

@QuantumInformation I have the exact same problem as you, maybe it is related to this. I'm trying @pimterry's workaround right now

@cespinoza-loga

This comment has been minimized.

Copy link

cespinoza-loga commented Nov 30, 2017

@QuantumInformation Use @pimterry's suggestion, I just tried and it works

@cotsog

This comment has been minimized.

Copy link
Member

cotsog commented Nov 30, 2017

@QuantumInformation: sorry for the troubles. Could you send an e-mail to support [at] travis-ci [dot] com with the name of your repo and a link to the failing build(s)? Thanks!

@banks

This comment has been minimized.

Copy link

banks commented Nov 30, 2017

An alternative workaround that might be possible for some and is working for me is to add --no-sandbox option to whatever is running chrome.

In my case I could add it to the browser options in testem.js to have ember tests run again.

This is a terrible workaround since running not in sandbox is far from ideal even in test env, but it might be better than running everything a sudo depending on your setup!

Will revert as soon as the fix is found. Thanks for looking at this promptly.

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Nov 30, 2017

--no-sandbox works for me, happy days

@dzahler

This comment has been minimized.

Copy link

dzahler commented Nov 30, 2017

I'm doing builds with just the sudo setting. i did not need to add the ownership changes for chrome.

This is in a BLT build for Acquia.

chalin added a commit to chalin/site-www that referenced this issue Nov 30, 2017

kevmoo added a commit to dart-lang/logging that referenced this issue Jan 18, 2018

kevmoo added a commit to dart-lang/logging that referenced this issue Jan 18, 2018

kyamaguchi added a commit to kyamaguchi/capybara-sessionkeeper that referenced this issue Jan 18, 2018

y-yagi added a commit to y-yagi/rails that referenced this issue Jan 18, 2018

Enselic added a commit to Enselic/sequencediagram.io that referenced this issue Jan 18, 2018

eileencodes added a commit to rails/rails that referenced this issue Jan 18, 2018

Fix ActionView UJS build
The UJS build has been failing with Chrome failed to start. This commit
fixes it by adding the option `--no-sandbox`. Travis removed the sanbox
option which is why Chrome crashes.

Ref travis-ci/travis-ci#8836

Example failure: https://travis-ci.org/rails/rails/jobs/330396750

JamesMessinger added a commit to APIDevTools/swagger-parser that referenced this issue Jan 18, 2018

mangui added a commit to video-dev/hls.js that referenced this issue Jan 18, 2018

@simonv3

This comment has been minimized.

Copy link

simonv3 commented Jan 18, 2018

This started happening again to us - I first noticed it a couple of days ago, and only now got around to adding the sudo bit to travis.yml. From the linked ticket #1668 it sounds like this has to do with responses to spectre/meltdown?

@meatballhat

This comment has been minimized.

Copy link

meatballhat commented Jan 19, 2018

@spencer-brown Thanks for asking for details. I should have explained more earlier.

The vulnerabilities are not with Chrome itself, but with the changes we would need to make to the way our containers run in order to get sandboxed Chrome to work. The only solutions we have found so far all involve escalating the privileges of the container to a degree that would mean other containers would be vulnerable to attack from the escalated container.

This doesn't even touch on the fact that we currently spin up all containers with the same container and host configuration regardless of the job's configuration (expanded/parsed .travis.yml). Changing how we spin up containers is a non-trivial change, as the program involved (travis-worker) cannot be quickly redeployed without disrupting all jobs a given process is managing. We are working to change this, but it is a long-term project that has historically been bumped for weeks or months in order to address interruptive or higher priority work.

I hope this helps better explain the reasoning behind recommending --no-sandbox when running in container-based Linux. Please do ask more questions if I'm missing stuff!

@gkalpak gkalpak referenced this issue Jan 19, 2018

Closed

ci: use `sudo: false` on Travis #21641

1 of 3 tasks complete

meatballhat added a commit to meatballhat/headless-karma-travis that referenced this issue Jan 19, 2018

Require sudo-enabled Linux on Travis
I am proposing this change to address recent changes to container-based Linux                                                                                                                                                                  
at Travis.  There are extensive comments available in [this                                                                                                                                                                                    
issue](travis-ci/travis-ci#8836), but the gist is                                                                                                                                                                    
that container-based Linux can no longer support sandboxed Chrome.  Either this                                                                                                                                                                
change or the addition of `--no-sandbox` will suffice.  I'm happy to propose                                                                                                                                                                   
changes to the referencing blog post, too 😺.
@spencer-brown

This comment has been minimized.

Copy link

spencer-brown commented Jan 19, 2018

got it, thanks @meatballhat !

@BanzaiMan

This comment has been minimized.

Copy link
Member

BanzaiMan commented Jan 19, 2018

I'm locking this issue now, to prevent further updates to this issue.

@travis-ci travis-ci locked as resolved and limited conversation to collaborators Jan 19, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.