Hacker News Reader

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

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?

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

Hi! I maintain a "curl | bash" installer script [1][2].

    such as only working on specific variants of Ubuntu,
    with specific packages installed in specific version,
    and/or RedHat

Our installer is capable of automatically installing dependencies on current versions of Debian, Ubuntu, and CentOS. If you're running something else it prints out "This doesn't appear to be a deb-based distro or an rpm-based one. Not going to be able to install dependencies. Please install dependencies manually and rerun with --no-deps-check.", which seems pretty reasonable to me?

    submit this data to that platform as an
    debian/{control,etc} to make a .deb or specfile for
    .rpm or PKGBUILD or whatever, and use the platforms
    _build tools_ to generate a platform specific package
    - be a package mantainer if you have to

Building a binary package for ngx_pagespeed isn't really practical. It needs to depend on nginx, but nginx doesn't have an ABI, so it needs to be built from source alongside your existing nginx or as part of a new nginx install. Getting into the distributions, so that they can build the ngx_pagespeed module at the same time as they build their main nginx would work, and is somewhere I would like to be eventually, but requires a lot of coordination with distros.

    Another side effect of telling your users to curl | bash,
    is I wont ever use your software. You didnt make the
    effort to do the right thing with packaging, why would
    you have done any better for whatever it is youre trying
    to do with your shit software?

I do think what we've done in this case is "the right thing" in terms of how we should be spending our development time. Our installation page does still offer manual install instructions, however, for people who would rather not run a script.

[1] https://developers.google.com/speed/pagespeed/module/build_n...

[2] https://ngxpagespeed.com/install

> Our installer is capable of automatically installing dependencies on current versions of

So you dirty the system where its supposed to be installed, a server, with gcc, make and friends?

> . If you're running something else it prints out "This doesn't appea

State so on your documentation/page before telling the user curl | bash, as I wrote in another post here, that is nice.

Your script does not support transactionional installations, as it is it can break at any point in the script and leave the target system broken/dirty. With a simple PKGBUILD youd also have solved the "binary ABI" part. If it really is tedious to coordinate with several distros, you can take a shortcut and dont deliver a "pkgspeed-for_nginx_module-1.2.3@v1.2" package but instead a "pkgspeed-1.2.3" which conflicts with the normal nginx package and thats it.

    So you dirty the system where its supposed to be
    installed, a server, with gcc, make and friends?

That's the way nginx is traditionally installed, and we're shipping an nginx plugin.

    State so on your documentation/page before telling the
    user curl | bash

The first thing the install script does is check if you're on a supported system, and if not it exits. Since the vast majority of people running the script are on supported systems, this seems better than putting a lot of warnings up front.

    Your script does not support transactional
    installations, as it is it can break at any point
    in the script leave the target system broken/dirty

By default the script only builds ngx_pagespeed, and doesn't install it. If you ask it to handle the install, it call's nginx's "make install", which again is the standard way you install nginx.

> That's the way nginx is traditionally installed

No. That is not how nginx is traditionally installed.

You misunderstand basic Linux package management and build systems, which is why you end up in this mess. But thats okay, world is keepin on spinnin. To each their own.

Don't all the same criticisms apply to `./configure && make install`?

Sure, so make it clear what curl | bash is, tell your users "we dont have any packages for your system, here is the source and we use X build tool, please do ./configure && make install, or cmake or whatever", that would have been nice.

When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur.

And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above.

So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?

For Sandstorm in particular, it doesn't necessarily run inside a container since it is itself a container management / sandbox tool, makes use of seccomp protections, etc. I'm not sure what the best way to sandbox Sandstorm is. Maybe get a separate VM instance.

(I am a Sandstorm fan, but I don't have it installed because it wants me to flip some sysctl about user namespaces or something, and I don't currently have a separate machine to do that on)

> it wants me to flip some sysctl about user namespaces or something

FWIW, this is no longer needed! Sandstorm has been updated to work without user namespaces and this installer script change will remove the check from the installer (will probably ship this week):

https://github.com/sandstorm-io/sandstorm/pull/2656

(You will need to let Sandstorm start as root if you don't want to flip the sysctl, though.)

> You will need to let Sandstorm start as root

Joke of today, thanks for the laugh.

What do you run as root that isn't accessible to other users on your system, and why are you deploying Sandstorm on this machine?

If it's a single-user machine, any process running at any privilege level can trivially get root by editing ~/.bashrc and aliasing the sudo command.

Aliasing the sudo command? Are you serious?

I dont even have sudo, let alone if I had it, I wouldnt use its dumb caching of credentials/session or "ask no password" "feature".

Just because my system is single-user doesnt mean I run every process with that one user, in fact I run firefox as its own user, chrome has its own, mpd as its own user, nginx is its own user and so on. This is basic security practice.

If you seriously think that it is so easy to get root just because you can run a process as a normal user - "by aliasing sudo command", then by all means run everything as root, whats the harm or big deal, right? Why do you even have a user which is non-root?

Why cant sandstorm run like lighttpd or nginx - as their own user, requiring no capabilites, in fact even syscalls can be revoked from them with seccomp and they will still work fine. All they need is socket api, file system api ( open close create), and some others, no they dont need to load kernel modules, ptrace or open_file_handle_at and so on.

nginx usually needs to start as root, in order to bind low-numbered ports, but the worker processes run as non-root.

Sandstorm works exactly the same way.

nginx can run as completely non-root, if you are OK with high-numbered ports.

Sandstorm can too, if you are OK with high-numbered ports and if unprivileged user namespaces are enabled.

(It sounds like you actually use UID separation for security on a desktop. That's cool, although keep in mind that if everything is talking to the same X server, then UID separation probably doesn't help much. If you're serious about this approach you should probably be using QubesOS.)

In theory yes, but in my experience ./configure && make install is a lot more reliable.

Projects that recommend piping curl to bash are trying to dumb down the process, and they have a tendency to make too many assumptions about the system it'll be running on.