sandstorm icon indicating copy to clipboard operation
sandstorm copied to clipboard

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

Open troyjfarrell opened this issue 4 years ago • 2 comments

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.

troyjfarrell avatar Dec 17 '20 05:12 troyjfarrell

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.

zenhack avatar Dec 17 '20 15:12 zenhack

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).

kentonv avatar Dec 24 '20 20:12 kentonv