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

Sandstorm tests fail on Debian/Ubuntu without kernel.unprivileged_userns_clone=1 #3477

Open
troyjfarrell opened this issue Dec 17, 2020 · 2 comments

Comments

@troyjfarrell
Copy link
Contributor

As documented on the mailing list, Sandstorm tests fail on Debian and Ubuntu without the sysctl kernel.unprivileged_userns_clone=1. I suggest that the test running script document this failure and suggest a resolution. I'm happy to create the PR, but I'd like to know if we should change install.sh so that it suggests resolution instead of giving up silently or if we should add a test for this known failure in tests/run-local.sh.

@zenhack
Copy link
Collaborator

zenhack commented Dec 17, 2020

Hm, normally this failing really isn't fatal, since if you're doing a system-wide install it starts up as root and can use the privileged sandbox, so under normal usage install.sh probably should do what it does now.

But, if you're running the tests then yeah, this is going to make stuff not work. Maybe we could add a flag for the install script to use 'test appropriate settings' rather than using the 'app developer defaults' for both.

Also, I wonder if it might make some sense to provide a way to run the tests with sandstorm started as root anyway -- there are some code paths that only run if we start up as root, and so the current setup means we can't write automated tests for those.

@kentonv, interested in your thoughts here too.

@kentonv
Copy link
Member

kentonv commented Dec 24, 2020

Getting the tests to run with root privileges seems like it would lead to a lot of issues so I don't feel like that's really worth the effort. The sandbox code is very low-level and almost never changes, which makes it unlikely to break.

I suppose the test script could contain some sort of check for unprivileged_userns_clone and tell the user what they need to do. Note that IIRC this sysctl is unique to Debian-derived systems. We would need to write some code that tests user namespaces by actually trying to create one, rather than checking the value of the sysctl.

Throwing something in the readme also seems like a fine answer.

Note that I don't think we should change install.sh -- the problem here applies to the tests only, not to real installs (where we have root privs).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants