A quick example - RVM!

http://rvm.io suggests you run the command:

\curl -L https://get.rvm.io | bash -s stable

Which exhibits exactly the failure scenario outlined in the article; partway through the script RVM cleans up after itself by running "rm -rf ${rvm_src_path}"

Simple changing this to

"\curl -L https://get.rvm.io > /tmp/rvm.sh && bash /tmp/rvm.sh stable"

Would eliminate the potential for nasty failures, with a minimum of fuss.

Actually, just changing it to "wget -O - https://get.rvm.io | bash -s stable" would work fine.

Of course, doing it the way you describe creates a /tmp race condition, so there's that.

I'm also curious what you think a partial read of "rm -rf ${rvm_src_path}" might resolve to that would be dangerous.

But there's no / in that command, or any way for it to rm the wrong directory, unless I'm misunderstanding something.

You're right, I'm completely wrong - the worst thing that can happen here is that the whole RVM directory is removed. Hardly catastrophic, and definitely not the extreme failure case the article is talking about.

There's no guarantee where $rvm_src_path will point to.

> The amount of projects that do this is absurd. People have been saying this for ages and nobody seems to listen. You could have all sorts of fun based on the user agent, as well: if it looks like a normal browser, send the harmless script. If it's curl or wget, prepend "echo 'I hope you are not going to pipe this into /bin/sh'; exit 1".

It's not really absurd. In truth, this roughly equivalent to what people would do if you had them download the code, unpack it, and go to work.

What the author doesn't seem to know is that if the web server returns Content-Length (which the project really ought to ensure, and all the ones I've seen do), then wget will by default keep retrying until such time as the entire content stream has been successfully downloaded. If you Ctrl-C out of it, both wget and the shell process will terminate without processing any partially downloaded statements. The one liner is just automating the tedious manual steps that people would otherwise do, and arguably doing a better job of it than most.

You can and should do better (which is why package managers exist), but this is better than what a lot of people do if you don't provide the one liner. If you look at the commands in most one-liner shell scripts, there usually aren't a lot of destructive things like "rm" in them either.

Now, it'd still be better to do these one-liner shell scripts as shell archive whose last line extracts and runs the actual script, and you could use gzip encoding to provide some extra sanity checking, but for the most part one liner scripts are not the problem.

That web PXE boot is pretty cool though. Don't try it at home, do it at a friend's house.

Don't mess up/risk your own computer just your friends... You must have trusting friends. lol

Well, that depends. What if they're not friends but "friends?"

LOL fair enough, fair enough

That's not really different from piping to shell, risk-wise.

Yes it is. If I'm piping to a shell as an unprivileged user, there needs to be an additional round of exploits to do nastiness to other than that user.

For those whose security model looks like http://xkcd.com/1200 that's not a big difference; but depending on context it might be.

But your unprivileged user account is going to have all the stuff that matters anyway.

I raised that point with the comic. Frequently that's the case, in which case yes, not much different (though maybe it's less likely to do hardware damage, maybe...). It's not always the case.

Why is it "ultimate bravery"? Unless you compile your own kernel, the Linux kernel many of you are using right now is "arbitrary". That is, someone else compiled it and you are trusting that what it will do (or initiate, via init, for example) when you boot it is acceptable. My guess is most Linux users do not compile their own kernels.

Perhaps the problem here is not that these project "developers" are suggesting that others pipe unread scripts into /bin/sh, it's that too often these "developers", or the others on the receiving end of their scripts, have a poor understanding of shell scripting.

I find in the majority of cases where someone wants me to run their shell script, I could do what needs to be done without using the script or rewrite the script myself, using a minimal POSIX-like shell instead of bash or ksh, and reducing script size by 90% or a similarly large percentage. Then there's the minority of cases where I actually admire the care that the script author took to make the script efficient and portable, or where I actually learn something new by reading the script. That happens all too rarely.

While I'm on the topic of shell scripting, I'll add that I do a lot of shell scripting for my own personal use. Since no one else ever has to read my scripts, I take the luxury of ignoring the Shift key and write all my scripts in lowercase. I have no need for uppercase variable names; they only slow me down.

I note that djb also writes his shell scripts in lowercase. For whatever it's worth, I consider him to be one of the world's best open source programmers, and a competent shell scripter.

That's not really intended as a serious application though - but being able to boot over long distance HTTP links is a nice advantage for a lot applications. Plus you can use HTTPS with that.

I know that particular case isn't serious, but it is definitely cool tech.