Re: bash - safely pass untrusted strings?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux