3 ms·

It was badly written, it was checking /etc/lsb-release instead of actually checking for that feature, and I hope you dont rely today on /proc/config for "checki

by antocv 10y ago

It was badly written, it was checking /etc/lsb-release instead of actually checking for that feature, and I hope you dont rely today on /proc/config for "checking for the feature" since /proc/config is not available but maybe the feature actually is. Anyway good job for fixing it. In any case, I doubt your sandbox today would work in my sandbox. That is kind of the point, why cant you ship an application which runs as a normal user only, why do you require root for everything and assume your sandstorm will be the machine-manager? Last time I tried, you actually recommended curl shit | sudo bash. sudo! Nevermind I hate sudo and dont have it. If you need sudo, take it/ask for it, specifically for that 1 operation, not for whole install script. Maybe thats how its done today?

kentonv 10y ago
> it was checking /etc/lsb-release instead of actually checking for that feature No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed: https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150ebc97dd55fd53e74a2305a863ab/install.sh#L518 https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150... We have never relied on /etc/lsb-release nor /proc/config. > why cant you ship an application which runs as a normal user only First, we're not shipping an application, we're shipping an application platform which includes a container engine. On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all. Unfortunately, Arch explicitly turns off user namespaces in their kernel build. Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.) If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM. > Last time I tried, you actually recommended curl shit | sudo bash. We have never recommended that.

by antocv 10y ago

kentonv 10y ago

> it was checking /etc/lsb-release instead of actually checking for that feature No it wasn't. The install script ran a little program that actually attempted to invoke the system call to see if it failed: https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150ebc97dd55fd53e74a2305a863ab/install.sh#L518 https://github.com/sandstorm-io/sandstorm/blob/800d1c016c150... We have never relied on /etc/lsb-release nor /proc/config. > why cant you ship an application which runs as a normal user only First, we're not shipping an application, we're shipping an application platform which includes a container engine. On systems that have unprivileged user namespaces available, you actually can install and run Sandstorm as a regular user -- no root privileges at all. Unfortunately, Arch explicitly turns off user namespaces in their kernel build. Without user namespaces, we have no choice but to require root privileges, because the Linux system calls for setting up containers require either root or user namespaces. (Note that Sandstorm is careful with its root privs -- most of the system runs as a regular user, calling out to a separate daemon for the specific operations that need root.) If you don't want to give Sandstorm root -- which is perfectly understandable -- and you don't want to enable the kernel features that allow it to be non-root, then you'll need to run it in a dedicated VM. > Last time I tried, you actually recommended curl shit | sudo bash. We have never recommended that.