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?
--
--
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
