3 ms·

> Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. > Sandstorm.io looking at you. That's hardly fair

by kentonv 10y ago

> Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. > Sandstorm.io looking at you. That's hardly fair, since the reason the Sandstorm installer fails on Arch is because it explicitly checks for the presence of a required kernel feature, and Arch explicitly doesn't have that feature. The installer script fails intentionally because of the missing feature, not because it is badly written. Shipping an Arch package wouldn't have magically made Sandstorm be able to work without the required kernel features. OTOH, if you build a custom kernel that has the necessary features, the Sandstorm installer will run just fine on Arch. (Coincidentally, we plan to lift this restriction this week, as we recently implemented an alternate sandbox design which doesn't require this feature.)

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 kentonv 10y ago

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.