[CentOS] bash - safely pass untrusted strings?
Benjamin Smith
lists at benjamindsmith.com
Tue Feb 26 20:40:06 UTC 2008
On Tuesday 26 February 2008, Garrick Staples wrote:
> > 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
>
> You need to quote the variable:
> #!/bin/bash
> echo "$1"
You missed the point.
In script2.sh, $1 only contains the string "this". There is no safe way to
pass $1 (containing string "this parameter") from script1 to script2 as a
single, trustable parameter.
You can't do it. Bash is incapable of passing a parameter safely.
You can sorta do it with *$ in the case of spaces. But this is all but
powerless against file names containing quotes or other "special" characters.
See below Disney example.
So $1 in script 1 contains "this parameter". $1 in script 2 contains "this".
Instead, I have to hork it up with awk, sed, or something similar, and try to
account for every possible interpreted character.
(I'm feeling that powerful goodness already! =)
> > 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;
>
> You are missing two sets of quotes:
> #!/bin/bash
> PassToShell2="escapethis $1"
> script2.sh "$PassToShell"
You missed the point here too. Maybe, to make it more clear, try this:
#!/bin/bash
PassToShell2=`escapethis $1`;
script2.sh "$PassToShell"
escapethis is intended to be a call, not a parameter. Please re-read my
earlier note with this new understanding?
> [...snip blah blah rant...]
>
> > 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.
>
> That's a bug in the script.
>
> It should be:
> mv -- "$file" "$file$suffix"
Again, you're missing the point. (practice makes perfect?)
While this "--" on the mv line is a good way to work around the fact that "-a"
is being interpreted, it doesn't change the fact that $file is unescaped.
The "-a" can be part of a file called "Disney Trip -a mother's journey.doc"
No amount of quoting the on the mv line will change the fact that there is no
way to pass a parameter SAFELY. "-a" is an example that can be matched by
files with quotes, doublequotes, dashes, semicolons and other characters.
Never do we actually have a trustable value in $file, only an interpreted
one.
Bash is incapable of passing a parameter SAFELY.
Here are the offending lines:
for file in $*
do
mv ${file} $prefix$file
done
But you didn't read that, did you? Try it yourself!
echo blah > "Disney trip -a mother\'s journey.doc";
I tried the following code with the above example. Note the quotes!
for file in $*
do
echo "$file";
done;
called like:
/bin/bash ../test.sh *
Disney
trip
-a
mother\'s
journey.doc
5 parameters, one file. Wheeeee!
Bash is incapable of passing a parameter Safely. No amount of quoting will
make TLDP's "move a bunch of files" script actually work reliably.
> > 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
>
> Just another case of missing double quotes.
(Sigh) You missed the point... (see above about bash being incapable of
passing a parameter safely)
Explain to "me" where 'ANY' amount 'of' quoting will "fix" this ? If only to
yourself... You can sorta do it with `find -print0`, a whispered admission to
a bloated, blaring, gaping white elephant of a problem.
I'd like to have a informed discussion, which, apparently, you either aren't
interested in, or aren't capable of.
Maybe if I alter the case?
bASH IS INCAPABLE OF PASSING A PARAMETER safely.
bAsH iS iNcApAbLe Of PaSsInG a PaRaMeTeR sAfElY.
I mean, argue with me if you want on how my scripts are implemented but the
previous two (TRUE) sentences sound like a philosophical deficiency to me.
But seriously, why do you consider this OK? Is it an ego thing?
-Ben
--
Only those who reach toward a goal are likely to achieve it.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the CentOS
mailing list