On Tuesday 26 February 2008, Les Mikesell wrote:
WHY THE @!#! NOT?!?!?
The shell is 'supposed' to be run by a user that is allowed to run any command he wants, and permission/trust issues are handled by the login/authentication process that happens before you get to the shell. If you give the shell a bad command under your own account, it's not supposed to second guess what you wanted.
I'm not asking for this. I'm only asking for the option to be able to trust that a parameter is... a parameter. EG:
file: script1.sh #! /bin/bash script2.sh $1 exit 0;
file: script2.sh #! /bin/bash echo $1;
$ script1.sh "this\ parameter";
I get output of "this"! script2 gets two parameters! I want a way for 1 parameter to STAY 1 parameter upon request, so that script2.sh would output "this parameter", like
file:script1.sh #! /bin/bash PassToShell2=escapethis $1; script2.sh $PassToShell; exit 0;
Bash is used, extensively in many cases, to deal with untrusted data.
Why?
How about an installer script? How about a magical script copied from TLDP to rename all files in pwd?
This can include random file names in user home directories, parameters on various scripts, etc. It's highly sensitive to being passed characters that have, over the past NN years, resulted in quite a number of security holes and problems.
If it hurts, don't do it. Build your own argument list and exec programs directly if you want to avoid shell command line parsing.
So, I'm supposed to know the contents of a user's home directory? And code for these in advance?
Yet there exists NO MECHANISM for simply ensuring that a given argument is
an
escaped string?
What does that mean? If you can define it you can make it happen, but who knows what characters at what depth of quoting will have some special meaning?
Can I define it? Thought I did that already: http://us.php.net/manual/en/function.escapeshellarg.php
Or its perl equivalent: http://search.cpan.org/~gaas/URI-1.35/URI/Escape.pm
See how I'd like to see it in implementation in above example, "passToShell2"
How many "homebrew" ISP or hosting administration scripts could be
compromised
by simply putting a file in your home directory called ";rm -rf /" ?
Probably none that are still in business.
Google "bash howto" for lots of vulnerable and problematic examples. Here's a beaut that fails if you have a file called "-a" in the pwd, see "File re-namer". It's a renamer that doesn't, if the file contains any spaces, dashes, etc.
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-12.html#ss12.1
Here's what I get:
mv: invalid option -- a Try `mv --help' for more information.
Or with a file with a space: echo "blah" > "d"; echo "blah" > "d foo";
The TLDP's example doesn't move file "d foo". I get: mv: cannot stat `d': No such file or directory mv: cannot stat `foo': No such file or directory
So I ask again: This doesn't strike you as fundamentally borkeD? The emperor wears no clothes!
This doesn't strike you as fundamentally borkeD?
No, if you stop bad things from happening, you'll also stop good things.
Yes. But you don't have to stop the good things. I think the *OPTION* of saying "parameter 1 is STILL parameter 1" is a good thing. If you want to leave things be, so be it. See my above example.
Why would we accept a work environment that is effectively laden with randomly placed, loaded rat
traps?
Not trying to bash (ahem) bash needlessly, but this is a problem that so smacks of 1977...
The problem is that you aren't using the shell as intended. If you run it under your own user id, it does exactly what you tell it to do and there is no element of trust involved.
The problem, as I see it, is that the shell provides access variables without any means of preserving them as variables across calls and incantations.
I guess I just hadn't noticed how bad this was, since I started using PHP
as
shell scripts years ago to run everything, despite the mild performance
hit.
escapeshallarg() and addslashes() combined with a few backticks provides
easy
access to the power of the shell, and excellent "don't need to worry about it" security.
Errr what??? Php has about the worst security history of any program around.
Thanks for confusing the issue with a red herring. Or should I ignore the buggy and probably vulnerable TLDP example above? Maybe a google search for "bash escape vulnerability" might illuminate the issue I speak of?
This just blows my mind....
What would you like your computer to prevent you from doing to yourself?
I hate to belabor it: give me the OPTION to trust that I can keep a single parameter as a single parameter across incantations and calls. If I'm looping thru a listing files, I should be able to trust that my $FILENAME variable contains the name of... a file! If I want to pass parameter 1 of my script to another script, that other script should be ABLE get my parameter 1 as... parameter 1!
A simple call that lets me take a string and get a passable parameter would suffice.
You want to apply scripts that break with a space in a file name? Great. Have at it. I don't want to detract from your ability to make an alphabet soup of your directories with borken examples from TLDP, and all the goodness that implies to you.
But I think admins the world over would like it if a simple, one-liner could be added to ensure that a single parameter remains a single parameter!
Am I being unclear?