[22317] in Perl-Users-Digest
Perl-Users Digest, Issue: 4538 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 10 18:47:49 2003
Date: Mon, 10 Feb 2003 15:46:37 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 10 Feb 2003 Volume: 10 Number: 4538
Today's topics:
Perl operators in variables <jamesrallen@att.com>
Re: Perl operators in variables (Tad McClellan)
Re: Perl operators in variables (Malcolm Dew-Jones)
Re: Perl operators in variables <goldbb2@earthlink.net>
Re: Perl operators in variables <ubl@schaffhausen.de>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <tassilo.parseval@post.rwth-aachen.de>
Re: Perl operators in variables <uri@stemsystems.com>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <bigj@kamelfreund.de>
Re: Perl operators in variables <uri@stemsystems.com>
Re: Perl operators in variables <uri@stemsystems.com>
Re: Perl operators in variables <bart.lateur@pandora.be>
Re: Perl operators in variables <jurgenex@hotmail.com>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <ajglist@izzy.net>
Re: Perl operators in variables <tassilo.parseval@post.rwth-aachen.de>
Re: Perl operators in variables <uri@stemsystems.com>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <tassilo.parseval@post.rwth-aachen.de>
Re: Perl operators in variables <abigail@abigail.nl>
Re: Perl operators in variables <tassilo.parseval@post.rwth-aachen.de>
Re: Perl operators in variables <bart.lateur@pandora.be>
Re: Perl operators in variables <jamesrallen@att.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 7 Feb 2003 17:53:39 -0500
From: "James R. Allen II" <jamesrallen@att.com>
Subject: Perl operators in variables
Message-Id: <b21bab$po124@kcweb01.netnews.att.com>
Is it possible to use a variable with it's value being a valid Perl operator
in a conditional?
i.e.
my $operator = "=~";
if ($text $operator /[abc]/) {
do something...
}
------------------------------
Date: Fri, 7 Feb 2003 17:23:44 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Perl operators in variables
Message-Id: <slrnb48g00.i8v.tadmc@magna.augustmail.com>
James R. Allen II <jamesrallen@att.com> wrote:
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
Why do you want to use a variable with it's value being a valid
Perl operator in a conditional?
There is likely a "better way", but we need to know what you
really need to accomplish before we can suggest one.
> i.e.
Surely you meant e.g. instead.
If it was i.e. it would not be variable.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
"=~" and "!~" are the only two operators that take the pattern
match operator as an operand.
Maybe you just chose a poor example?
You could cobble something together with string eval() but
that could be very very dangerous...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 7 Feb 2003 15:40:58 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Perl operators in variables
Message-Id: <3e44440a@news.victoria.tc.ca>
James R. Allen II (jamesrallen@att.com) wrote:
: Is it possible to use a variable with it's value being a valid Perl operator
: in a conditional?
: i.e.
: my $operator = "=~";
: if ($text $operator /[abc]/) {
: do something...
: }
perldoc -f eval
Understand that eval builds a new perl program that can do anything your
main program can do, so be careful what is in the strings you use to build
that new program. Read up on taint mode.
Usefully, and perhaps not obvious at first, you don't have to build entire
(small) programs to use eval, you can use it just to get a single value
$one = 1;
$two = 2;
$op = '>';
print " $one $op $two " if eval " $one $op $two " ;
$op = '<';
print " $one $op $two " if eval " $one $op $two " ;
# NOTE THIS EXAMPLE OF THE DANGERS OF EVAL
# if this were uncommented then it runs just fine
# and deletes a file.
# $op = '; system("del m.m"); ';
# print " $one $op $two " if eval " $one $op $two " ;
------------------------------
Date: Fri, 07 Feb 2003 23:57:42 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Perl operators in variables
Message-Id: <3E448E46.7F5895EA@earthlink.net>
"James R. Allen II" wrote:
>
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
>
> i.e.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
> do something...
> }
my $operator = sub { $_[0] =~ $_[1] };
if( $operator->( $text, qr/[abc]/ ) ) {
...do something...
}
--
"So, who beat the clueless idiot today?"
"Well, we flipped for it, but when Kuno
landed, he wasn't in any shape to fight."
"Next time, try flipping a *coin.*"
------------------------------
Date: Sat, 08 Feb 2003 16:43:49 +0100
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: Perl operators in variables
Message-Id: <b23br4$5jb$1@news.dtag.de>
James R. Allen II wrote:
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
>
> i.e.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
> do something...
>
As always, use a hash:
my %binary_ops = (
"=~" => sub { $_[0] =~ $_[1] }
);
my $op = "=~";
if( $binary_ops{$op}->( "word", qr/\w/ ) ) {
print "works"
}
->malte
------------------------------
Date: 08 Feb 2003 23:32:06 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4b4rm.sb.abigail@alexandra.abigail.nl>
Tad McClellan (tadmc@augustmail.com) wrote on MMMCDXLVII September
MCMXCIII in <URL:news:slrnb48g00.i8v.tadmc@magna.augustmail.com>:
))
)) You could cobble something together with string eval() but
)) that could be very very dangerous...
Yeah, but not more dangerous than editing a file with Perl code
in vi and then executing it.
I find the phrase 'string eval() could be dangerous' utterly
meaningless.
Abigail
--
perl -wle'print"Êõóô áîïôèåò Ðåòì Èáãëåò"^"\x80"x24'
------------------------------
Date: 9 Feb 2003 07:25:08 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Perl operators in variables
Message-Id: <b24vok$poi$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
> Tad McClellan (tadmc@augustmail.com) wrote on MMMCDXLVII September
> MCMXCIII in <URL:news:slrnb48g00.i8v.tadmc@magna.augustmail.com>:
> ))
> )) You could cobble something together with string eval() but
> )) that could be very very dangerous...
>
>
> Yeah, but not more dangerous than editing a file with Perl code
> in vi and then executing it.
>
> I find the phrase 'string eval() could be dangerous' utterly
> meaningless.
It is and it is not. We don't know why the OP wants to eval a statement
based on different operators. It's easily imaginable that he wants to
write a sort of calculator that should be accessible through CGI or so.
I think at least pointing out to him that eval() could cause trouble on
the long run is fair.
Other than that I agree. The dislike of string-eval in this group
sometimes seems a little too idiosyncratic.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sun, 09 Feb 2003 08:12:49 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl operators in variables
Message-Id: <x73cmxg9dr.fsf@mail.sysarch.com>
>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@post.rwth-aachen.de> writes:
TvP> Other than that I agree. The dislike of string-eval in this group
TvP> sometimes seems a little too idiosyncratic.
but abigail and you know how to apply string eval and where to use
it. the real issue is that newbies tend to not know other ways and fall
back on eval too quickly. sure it can look simpler and in some cases it
actually is. but newbies using eval wantonly will lead them to using it
where it is very dangerous. and they usually don't know safe areas from
dangerous. so the group dislike of eval is a parental smack on the
$BODY_PART telling the kiddie that they need to grow up more before
being handed the keys to the perl car.
too often kiddie uses of eval are easily solved with proper data
structure, declaring variables in the right scope, etc. string eval's
best use is for custom code generation which is rarely the goal when it
is used. the rule should be that you use string eval if there is no
other effective way to solve it. it is not the first solution in most
cases.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: 09 Feb 2003 10:42:36 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4cc4s.1l1.abigail@alexandra.abigail.nl>
Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
in <URL:news:x73cmxg9dr.fsf@mail.sysarch.com>:
|| >>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@post.rwth-aachen.de> writes:
||
|| TvP> Other than that I agree. The dislike of string-eval in this group
|| TvP> sometimes seems a little too idiosyncratic.
||
|| but abigail and you know how to apply string eval and where to use
|| it. the real issue is that newbies tend to not know other ways and fall
|| back on eval too quickly. sure it can look simpler and in some cases it
|| actually is. but newbies using eval wantonly will lead them to using it
|| where it is very dangerous. and they usually don't know safe areas from
|| dangerous. so the group dislike of eval is a parental smack on the
|| $BODY_PART telling the kiddie that they need to grow up more before
|| being handed the keys to the perl car.
In the hands of a newbie, eval isn't any more dangerous than vi.
I just don't buy it that it's ok to write a program and to compile
it, but that's oh so dangerous to do eval.
*eval is doing the same thing*
The danger is to assume that if you are running on behalf of someone
else, user supplied input is trustworthy. But by not using eval you
haven't solved that problem.
|| too often kiddie uses of eval are easily solved with proper data
|| structure, declaring variables in the right scope, etc. string eval's
|| best use is for custom code generation which is rarely the goal when it
|| is used. the rule should be that you use string eval if there is no
|| other effective way to solve it. it is not the first solution in most
|| cases.
But it ain't a dogma. I use string eval, and `` in many cases where
it could have all been done with "real" Perl operations. Sometimes,
run time efficiency just doesn't matter.
Abigail
--
perl -we 'print split /(?=(.*))/s => "Just another Perl Hacker\n";'
------------------------------
Date: Sun, 09 Feb 2003 13:07:23 +0100
From: "Janek Schleicher" <bigj@kamelfreund.de>
Subject: Re: Perl operators in variables
Message-Id: <pan.2003.02.09.11.46.13.476618@kamelfreund.de>
On Sun, 09 Feb 2003 08:12:49 +0000, Uri Guttman wrote:
>>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@post.rwth-aachen.de> writes:
>
> TvP> Other than that I agree. The dislike of string-eval in this group
> TvP> sometimes seems a little too idiosyncratic.
>
> but abigail and you know how to apply string eval and where to use
> it. the real issue is that newbies tend to not know other ways and fall
> back on eval too quickly. sure it can look simpler and in some cases it
> actually is. but newbies using eval wantonly will lead them to using it
> where it is very dangerous. and they usually don't know safe areas from
> dangerous. so the group dislike of eval is a parental smack on the
> $BODY_PART telling the kiddie that they need to grow up more before
> being handed the keys to the perl car.
>
> too often kiddie uses of eval are easily solved with proper data
> structure, declaring variables in the right scope, etc. string eval's
> best use is for custom code generation which is rarely the goal when it
> is used. the rule should be that you use string eval if there is no
> other effective way to solve it. it is not the first solution in most
> cases.
Perhaps we should add when it is really recommendable to use eval in the FAQ.
It's not acceptable that
perldoc -q eval
doesn't founds documentation for a beginner.
(perldoc -f eval exists of course, but it explains how to use eval and not
when)
I sure lack a bit of phantasy, but myself uses eval usually in 4
situations.
eval {
BLOCK
}
if ($@) {
...
}
to catch errors
eval <<ROUTINE_OR_SIMILAR;
sub foo {
...
many statements depending on some configurations
(or other values, not changing while foo() is used)
but executed a lot
e.g. filters
to increase the efficeny
(sometimes even better than any optimized c program,
that doesn't use gcc and a system call)
}
ROUTINE_OR_SIMILAR
eval <<PROTOTYPE for qw/foo bar foobar/;
sub something_with_$_ {
my \$self = shift;
\$self->{$_}++; # or whatever
#
# or however
}
PROTOTYPE
to avoid doubling code, what's a real crime.
In perl 1-4 liners, just to have fun.
Greetings,
Janek
------------------------------
Date: Sun, 09 Feb 2003 15:57:32 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl operators in variables
Message-Id: <x7r8ahe9as.fsf@mail.sysarch.com>
>>>>> "A" == Abigail <abigail@abigail.nl> writes:
A> In the hands of a newbie, eval isn't any more dangerous than vi. I
A> just don't buy it that it's ok to write a program and to compile
A> it, but that's oh so dangerous to do eval.
A> *eval is doing the same thing*
that isn't the case. writing a program is the primary level solution. using
eval is a secondary level solution. the fact that both compile code does
not equate them. we have all seen bad code and bad uses of eval. but
when a newbie uses eval for basic data manipulation (typically symref
type stuff like eval "\$$name = $value") they are just not doing it the
best way. this is not a relative evil thing or they can compile at any
time. it is bad code and they should be slapped.
A> || too often kiddie uses of eval are easily solved with proper data
A> || structure, declaring variables in the right scope, etc. string eval's
A> || best use is for custom code generation which is rarely the goal when it
A> || is used. the rule should be that you use string eval if there is no
A> || other effective way to solve it. it is not the first solution in most
A> || cases.
A> But it ain't a dogma. I use string eval, and `` in many cases where
A> it could have all been done with "real" Perl operations. Sometimes,
A> run time efficiency just doesn't matter.
it isn't a dogma for you and others who know what they are doing. the
key is always, was there a conscious decision behind this code? i trust
that your code won't use eval unless there was no other choice (japhs
and golf don't count :). a kiddie will hear about eval and use it as
their primary tool even though safer methods exist.
the key to the 'dogma' is to make sure newbies understand how dangerous
eval can be (and i don't mean security). and yes any code can be
dangerous but that is hand waving. we have seen too many newbies use
eval for no reason other than that is all they can do to solve
something. they need to be made aware it is not a good first cut answer.
what experts do and newbies do are different things. fire is good but
not for babies. sure a child can use a blowtorch or a lighter to start a
fire. which is safer for them and others? not all fire is the same and
not all compiling of code is the same.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Sun, 09 Feb 2003 16:02:54 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl operators in variables
Message-Id: <x7n0l5e91u.fsf@mail.sysarch.com>
>>>>> "JS" == Janek Schleicher <bigj@kamelfreund.de> writes:
JS> I sure lack a bit of phantasy, but myself uses eval usually in 4
JS> situations.
JS> eval {
JS> BLOCK
JS> }
JS> if ($@) {
JS> ...
JS> }
JS> to catch errors
that is block eval which has absolutey nothing to do with string
eval. block eval is not dangerous. string eval is.
JS> eval <<ROUTINE_OR_SIMILAR;
JS> sub foo {
JS> ...
JS> many statements depending on some configurations
JS> (or other values, not changing while foo() is used)
JS> but executed a lot
JS> e.g. filters
JS> to increase the efficeny
JS> (sometimes even better than any optimized c program,
JS> that doesn't use gcc and a system call)
JS> }
JS> ROUTINE_OR_SIMILAR
that is code generation on the fly which is something i already said is
string eval's primary purpose.
JS> eval <<PROTOTYPE for qw/foo bar foobar/;
JS> sub something_with_$_ {
JS> my \$self = shift;
JS> \$self->{$_}++; # or whatever
JS> #
JS> # or however
JS> }
JS> PROTOTYPE
that is better done as a closure which doesn't need eval. it is faster
and safer.
JS> In perl 1-4 liners, just to have fun.
i already exempted japhs from this 'dogma'. :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Sun, 09 Feb 2003 16:09:37 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Perl operators in variables
Message-Id: <e4vc4vslo1q9cmn0jhn88ka1cmam7g7ft5@4ax.com>
Janek Schleicher wrote:
>I sure lack a bit of phantasy,
The danger of eval is in code like:
$\ = "\n";
while(<STDIN>) {
print eval $_;
print "Error: $@" if $@;
}
to get a simple interactive calculator. It's even a lot worse if this
happens in a CGI script instead of using the command line.
--
Bart.
------------------------------
Date: Sun, 09 Feb 2003 16:56:51 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Perl operators in variables
Message-Id: <nLv1a.12710$F25.727@nwrddc02.gnilink.net>
Abigail wrote:
> In the hands of a newbie, eval isn't any more dangerous than vi.
> I just don't buy it that it's ok to write a program and to compile
> it, but that's oh so dangerous to do eval.
>
> *eval is doing the same thing*
>
> The danger is to assume that if you are running on behalf of someone
> else, user supplied input is trustworthy. But by not using eval you
> haven't solved that problem.
Very well said.
However, untrustworthy data which is input by a user of the program will
typically just cause a program failure and even novice programmers may
recognize that they better test the data for sanity.
Executing untrustworthy data with eval it's different in so far as a novice
programmer will typically not realize that he is handling user data as code
and that an eval allows the execution of any command , Perl or system(!).
Even a {system 'rm -rf /'} can be hidden in any eval argument.
Yes, you are right. The user can enter the same for any other data, too. But
if I the program tries to e.g. multiply that malicious code then you just
receive the wrong result. It may cause the program to fail, but usually it
doesn't cause quite as much harm as if the data is executed as code in eval.
In so far eval is in a risk class of it's own.
With proper analysis of the data before submitting it to eval this is not a
problem. Right. But who does that analysis, in particular which beginner
would do it when he isn't even aware that there is a potential risk?
In so far I think the warnings about eval are justified. People who know how
to use eval sensibly don't need to ask here how to use it.
jue
------------------------------
Date: 09 Feb 2003 18:57:55 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4d95j.2c1.abigail@alexandra.abigail.nl>
Jürgen Exner (jurgenex@hotmail.com) wrote on MMMCDXLIX September MCMXCIII
in <URL:news:nLv1a.12710$F25.727@nwrddc02.gnilink.net>:
:) Abigail wrote:
:) > In the hands of a newbie, eval isn't any more dangerous than vi.
:) > I just don't buy it that it's ok to write a program and to compile
:) > it, but that's oh so dangerous to do eval.
:) >
:) > *eval is doing the same thing*
:) >
:) > The danger is to assume that if you are running on behalf of someone
:) > else, user supplied input is trustworthy. But by not using eval you
:) > haven't solved that problem.
:)
:) Very well said.
:) However, untrustworthy data which is input by a user of the program will
:) typically just cause a program failure and even novice programmers may
:) recognize that they better test the data for sanity.
:) Executing untrustworthy data with eval it's different in so far as a novice
:) programmer will typically not realize that he is handling user data as code
:) and that an eval allows the execution of any command , Perl or system(!).
:) Even a {system 'rm -rf /'} can be hidden in any eval argument.
:)
:) Yes, you are right. The user can enter the same for any other data, too. But
:) if I the program tries to e.g. multiply that malicious code then you just
:) receive the wrong result. It may cause the program to fail, but usually it
:) doesn't cause quite as much harm as if the data is executed as code in eval.
There are lots of other functions that can be handed dangerous data:
system, qx, open, rename, unlink, to name a few. By focussing on "string
eval is dangerous" instead of "when running on behalf of someone else,
user supplied data is dangerous", you are suggesting that your program
becomes more secure if you shy away from using string eval. Which, IMO,
is even more dangerous.
User supplied data is the problem - not string eval. Furthermore, this
problem only happens when you are running as someone else: suid/sgid
programs or network daemons. Many, if not most, programs are not running
on behalf of someone else, so you wouldn't have this problem in the
first place.
:) In so far eval is in a risk class of it's own.
:) With proper analysis of the data before submitting it to eval this is not a
:) problem. Right. But who does that analysis, in particular which beginner
:) would do it when he isn't even aware that there is a potential risk?
So, spend your energy on teaching people to properly check data instead
of chanting the dogma "string eval is dangerous". Just like it's better
to teach children to watch out for traffic before crossing the street
than to tell them to not cross the street if they hear a truck.
:) In so far I think the warnings about eval are justified. People who know how
:) to use eval sensibly don't need to ask here how to use it.
Oh, come on. Then one could warn about using Perl in the first place.
After all, people who know how to use Perl sensibly aren't coming
here to ask questions.
Abigail
--
#!/opt/perl/bin/perl -- # Remove trailing newline!
BEGIN{$SIG{__WARN__}=sub{$_=pop;y-_- -;print/".*(.)"/;
truncate$0,-1+-s$0;exec$0;}}//rekcaH_lreP_rehtona_tsuJ
------------------------------
Date: 09 Feb 2003 19:04:31 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4d9hu.2c1.abigail@alexandra.abigail.nl>
Bart Lateur (bart.lateur@pandora.be) wrote on MMMCDXLIX September
MCMXCIII in <URL:news:e4vc4vslo1q9cmn0jhn88ka1cmam7g7ft5@4ax.com>:
@@ Janek Schleicher wrote:
@@
@@ >I sure lack a bit of phantasy,
@@
@@ The danger of eval is in code like:
@@
@@ $\ = "\n";
@@ while(<STDIN>) {
@@ print eval $_;
@@ print "Error: $@" if $@;
@@ }
@@
@@ to get a simple interactive calculator.
It isn't anymore dangerous than running 'sh'. If I type 'rm -rf /'
in 'sh', then my files are gone as well.
Having told you that, are you now going to warn people when they
are about to use 'sh'? If not, why not?
@@ It's even a lot worse if this
@@ happens in a CGI script instead of using the command line.
Yes. And there are a ton of other functions in Perl that are dangerous.
open() is at least as dangerous. But it would be silly to advocate to
no longer use open(), now would it?
Luckely, there's a way to safely use open(), even with user supplied
data. (Answer: validate the data). Now, that same technique will
safeguard you with eval. Why not focus on learning people one technique,
that will make *all* functions safe, instead of telling people not
to use one particular function, which is only unsafe in certain conditions,
and if those conditions are met, other functions are unsafe as well?
Abigail
--
perl -wleprint -eqq-@{[ -eqw\\- -eJust -eanother -ePerl -eHacker -e\\-]}-
------------------------------
Date: 09 Feb 2003 19:17:00 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4da9c.2c1.abigail@alexandra.abigail.nl>
Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
in <URL:news:x7r8ahe9as.fsf@mail.sysarch.com>:
-:
-: it isn't a dogma for you and others who know what they are doing. the
-: key is always, was there a conscious decision behind this code? i trust
-: that your code won't use eval unless there was no other choice (japhs
-: and golf don't count :).
You are wrong here. Sometimes I use eval just because it's more
convenient. Just like that I happely use qx() and system() even
if there's a Perl solution available, if I find it convenient.
-: a kiddie will hear about eval and use it as
-: their primary tool even though safer methods exist.
"A kiddie will hear about split() and use it as their primary tool
even though faster methods exist."
"A kiddie will hear about objects and use it as their primary tool
even though less awkward methods exits."
The wrong thing the newbie is doing here is assuming everything is a
nail once you have a hammer. The wrong thing the expert is doing here
is assuming that only eval will be seen as a hammer.
-: the key to the 'dogma' is to make sure newbies understand how dangerous
-: eval can be (and i don't mean security). and yes any code can be
-: dangerous but that is hand waving. we have seen too many newbies use
-: eval for no reason other than that is all they can do to solve
-: something. they need to be made aware it is not a good first cut answer.
I've often seen newbies trying to solve everything with a regexp.
Should I from now on wave red flags as soon as someone uses a regexp?
-: what experts do and newbies do are different things. fire is good but
-: not for babies. sure a child can use a blowtorch or a lighter to start a
-: fire. which is safer for them and others? not all fire is the same and
-: not all compiling of code is the same.
The wrong thing for the expert to do is telling that all fires should
be extinguished. You do want people to progress in their quest to
become a Perl wizard, don't you?
Abigail
--
perl -wle'print"Êõóô áîïôèåò Ðåòì Èáãëåò"^"\x80"x24'
------------------------------
Date: Sun, 09 Feb 2003 19:30:51 GMT
From: Alan Gutierrez <ajglist@izzy.net>
Subject: Re: Perl operators in variables
Message-Id: <L%x1a.15764$tQ1.1118535@news2.east.cox.net>
Abigail wrote:
> Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
> in <URL:news:x7r8ahe9as.fsf@mail.sysarch.com>:
> -:
> -: it isn't a dogma for you and others who know what they are doing. the
> -: key is always, was there a conscious decision behind this code? i
> trust
> -: that your code won't use eval unless there was no other choice (japhs
> -: and golf don't count :).
>
> You are wrong here. Sometimes I use eval just because it's more
> convenient. Just like that I happely use qx() and system() even
> if there's a Perl solution available, if I find it convenient.
>
> -: a kiddie will hear about eval and use it as
> -: their primary tool even though safer methods exist.
>
> "A kiddie will hear about objects and use it as their primary tool
> even though less awkward methods exits."
After all these years programming Perl, I am finally coming around to
the realization that I don't have to install two dozen CPAN modules for
basic tasks. That all these admonishments against using the UNIX toolset
qx() and system() are to be taken with a grain of salt.
--
Alan Gutierrez - ajglist@izzy.net
------------------------------
Date: 9 Feb 2003 19:45:58 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Perl operators in variables
Message-Id: <b26b5m$5kf$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
[ string-eval ]
> @@ It's even a lot worse if this
> @@ happens in a CGI script instead of using the command line.
>
> Yes. And there are a ton of other functions in Perl that are dangerous.
> open() is at least as dangerous. But it would be silly to advocate to
> no longer use open(), now would it?
>
> Luckely, there's a way to safely use open(), even with user supplied
> data. (Answer: validate the data).
Hmmh, as for open I would have guessed that the three argument form of
open() would be the best solution (given the fact that a program is to
open a file passed from the outside as string; I don't know whether you
were referring to this though).
It's a little more difficult with string-eval. I couldn't off-hand come
up with a good methodology to sanitize any input there. It's much harder
there. open(), system() etc all have in-built means to do it for me.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sun, 09 Feb 2003 22:04:28 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl operators in variables
Message-Id: <x7el6hdsb8.fsf@mail.sysarch.com>
>>>>> "A" == Abigail <abigail@abigail.nl> writes:
A> Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
A> in <URL:news:x7r8ahe9as.fsf@mail.sysarch.com>:
A> -:
A> -: it isn't a dogma for you and others who know what they are doing. the
A> -: key is always, was there a conscious decision behind this code? i trust
A> -: that your code won't use eval unless there was no other choice (japhs
A> -: and golf don't count :).
A> You are wrong here. Sometimes I use eval just because it's more
A> convenient. Just like that I happely use qx() and system() even
A> if there's a Perl solution available, if I find it convenient.
are you a newbie? i don't think so. :) i said if you understand the
choices involved and the issues with eval, then use it. newbies tend to
use it regardless and without even knowing other (and better) solutions
exist. you can't qualify this with your use of eval.
A> "A kiddie will hear about split() and use it as their primary tool
A> even though faster methods exist."
i never said faster, i said better. split is appropriate for many
problems. moronzilla always uses index over regexes. it can be faster
that way for some problems but it almost always is uglier code. you
would agree that regexes are generally a better solution for most
problems in that area.
A> "A kiddie will hear about objects and use it as their primary tool
A> even though less awkward methods exits."
you are just going to extremes. eval is a bad newbie tool.
A> I've often seen newbies trying to solve everything with a regexp.
A> Should I from now on wave red flags as soon as someone uses a regexp?
no, because regexes (without the /ee) are not going to cause action at a
distance bugs like eval can.
A> The wrong thing for the expert to do is telling that all fires
A> should be extinguished. You do want people to progress in their
A> quest to become a Perl wizard, don't you?
at some point in their perl growth, eval can be introduced. randal
schwartz's classes do the same thing. baby steps first and then you
unlearn some of those as they are not as effective. the baby step is not
to use eval. later you can use it when you have mastered other ways to
do things. eval is not a first choice.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: 09 Feb 2003 22:41:30 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4dm8q.2re.abigail@alexandra.abigail.nl>
Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
MMMCDXLIX September MCMXCIII in <URL:news:b26b5m$5kf$1@nets3.rz.RWTH-Aachen.DE>:
** Also sprach Abigail:
**
** [ string-eval ]
**
** > @@ It's even a lot worse if this
** > @@ happens in a CGI script instead of using the command line.
** >
** > Yes. And there are a ton of other functions in Perl that are dangerous.
** > open() is at least as dangerous. But it would be silly to advocate to
** > no longer use open(), now would it?
** >
** > Luckely, there's a way to safely use open(), even with user supplied
** > data. (Answer: validate the data).
**
** Hmmh, as for open I would have guessed that the three argument form of
** open() would be the best solution (given the fact that a program is to
** open a file passed from the outside as string; I don't know whether you
** were referring to this though).
See, you are proving my point. Validating the data is the answer, don't
get lured in the false sense of security "don't use string eval", "use
the three arg form of open".
open my $fh, ">", $file
is as unsafe as
eval $str
After all, $file could contain "/vmunix", or where ever you happen to
have your kernel.
** It's a little more difficult with string-eval. I couldn't off-hand come
** up with a good methodology to sanitize any input there.
IIRC, the OP asked about operators. I don't know about your Perl, but my
Perl has a small set of operators. It wouldn't be hard to test whether
a specific string contains an operator, and nothing but an operator.
Abigail
--
$_ = "\112\165\163\1648\141\156\157\164\150\145\1628\120\145"
. "\162\1548\110\141\143\153\145\162\0128\177" and &japh;
sub japh {print "@_" and return if pop; split /\d/ and &japh}
------------------------------
Date: 09 Feb 2003 22:53:05 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4dmuh.2re.abigail@alexandra.abigail.nl>
Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
in <URL:news:x7el6hdsb8.fsf@mail.sysarch.com>:
** >>>>> "A" == Abigail <abigail@abigail.nl> writes:
**
** A> Uri Guttman (uri@stemsystems.com) wrote on MMMCDXLIX September MCMXCIII
** A> in <URL:news:x7r8ahe9as.fsf@mail.sysarch.com>:
** A> -:
** A> -: it isn't a dogma for you and others who know what they are doing. the
** A> -: key is always, was there a conscious decision behind this code? i trust
** A> -: that your code won't use eval unless there was no other choice (japhs
** A> -: and golf don't count :).
**
** A> You are wrong here. Sometimes I use eval just because it's more
** A> convenient. Just like that I happely use qx() and system() even
** A> if there's a Perl solution available, if I find it convenient.
**
** are you a newbie? i don't think so. :) i said if you understand the
** choices involved and the issues with eval, then use it. newbies tend to
** use it regardless and without even knowing other (and better) solutions
** exist. you can't qualify this with your use of eval.
Actually, if you read back your own words, you said:
"I trust that your code won't use eval unless there was no other choice".
And I pointed out you were wrong about that. I do use eval, even if there's
an alternative.
** A> "A kiddie will hear about split() and use it as their primary tool
** A> even though faster methods exist."
**
** i never said faster, i said better. split is appropriate for many
** problems. moronzilla always uses index over regexes. it can be faster
** that way for some problems but it almost always is uglier code. you
** would agree that regexes are generally a better solution for most
** problems in that area.
**
** A> "A kiddie will hear about objects and use it as their primary tool
** A> even though less awkward methods exits."
**
** you are just going to extremes. eval is a bad newbie tool.
Well, 'eval is a bad newbie tool' is a long way from 'eval is dangerous'.
Not that you have me convinced that eval is bad for newbies. The only
things that I find bad for newbies are things that are overly complex.
That would include OOP, but certainly not eval.
** A> I've often seen newbies trying to solve everything with a regexp.
** A> Should I from now on wave red flags as soon as someone uses a regexp?
**
** no, because regexes (without the /ee) are not going to cause action at a
** distance bugs like eval can.
Actually, regexes have more side-effects (aka "distance at an action")
than eval has.
** A> The wrong thing for the expert to do is telling that all fires
** A> should be extinguished. You do want people to progress in their
** A> quest to become a Perl wizard, don't you?
**
** at some point in their perl growth, eval can be introduced. randal
** schwartz's classes do the same thing. baby steps first and then you
** unlearn some of those as they are not as effective. the baby step is not
** to use eval. later you can use it when you have mastered other ways to
** do things. eval is not a first choice.
It's quite unperlish to dictate how others should program. Could we leave
that to the Python department? eval is sometimes incredibly handy - so
handy that I would call languages that don't have a form of eval inferior.
Telling people not to use eval because it can be used in a wrong way is
just plain silly. It's like mom saying not to use knives when preparing
dinner because a knife could be used to cut of your finger.
Abigail
--
perl -wle 'eval {die [[qq [Just another Perl Hacker]]]};; print
${${${@}}[$#{@{${@}}}]}[$#{${@{${@}}}[$#{@{${@}}}]}]'
------------------------------
Date: 9 Feb 2003 23:13:17 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Perl operators in variables
Message-Id: <b26nad$h68$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
> Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
> MMMCDXLIX September MCMXCIII in <URL:news:b26b5m$5kf$1@nets3.rz.RWTH-Aachen.DE>:
> ** Hmmh, as for open I would have guessed that the three argument form of
> ** open() would be the best solution (given the fact that a program is to
> ** open a file passed from the outside as string; I don't know whether you
> ** were referring to this though).
>
> See, you are proving my point.
I don't know whether you realized, but it wasn't me you were disagreeing
with. Not yet at least. ;-)
> Validating the data is the answer, don't
> get lured in the false sense of security "don't use string eval", "use
> the three arg form of open".
>
> open my $fh, ">", $file
>
> is as unsafe as
>
> eval $str
>
> After all, $file could contain "/vmunix", or where ever you happen to
> have your kernel.
But this is a particularly unhelpful example. Usually the
file-permissions take care of that. So in a low-privilege context like
CGI this is impossible (unless configuration is borked).
It's easier to do harm with eval:
my $string = "fork while 1";
eval $string;
The above brings down the system even when run as nobody or whatsoever
unless ulimits are set (which might not be the case for a webserver
spawning children). You can't do it with open() as you seemed to imply.
> ** It's a little more difficult with string-eval. I couldn't off-hand come
> ** up with a good methodology to sanitize any input there.
>
> IIRC, the OP asked about operators. I don't know about your Perl, but my
> Perl has a small set of operators. It wouldn't be hard to test whether
> a specific string contains an operator, and nothing but an operator.
Really? Well, perlfunc lists the following numeric functions (I would
count those as operators):
"abs", "atan2", "cos", "exp", "hex", "int", "log",
"oct", "rand", "sin", "sqrt", "srand"
All of them can be arbitrarily deeply nested inside each other. A regex
matching only the good input and throwing away the garbage is quite
certainly above the head of the OP.
Also, in Perl line-noise (that possibly looks as though it mostly
consists of operators) can be a valid Perl script (I think you should
know that best considerung your notorious JAPHs).
No, I wouldn't want to take care of all that. I use eval() where I think
it is appropriate. This includes cases where it's not even necessary but
makes the code more terse or more elegant or whatsoever. But as soon as
I have the suspicion that string-eval could open a security hole I am
rather reluctant towards it. We didn't know in the OP's case. But having
defensive assumptions isn't that bad. After all: The OP learnt about
eval() but he may have also read the rest of the thread which is enough
to make him aware of potential problems.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 09 Feb 2003 23:42:17 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Perl operators in variables
Message-Id: <slrnb4dpqp.2re.abigail@alexandra.abigail.nl>
Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
MMMCDXLIX September MCMXCIII in <URL:news:b26nad$h68$1@nets3.rz.RWTH-Aachen.DE>:
** Also sprach Abigail:
**
** > Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
** > MMMCDXLIX September MCMXCIII in <URL:news:b26b5m$5kf$1@nets3.rz.RWTH-Aachen.DE>:
**
** > ** Hmmh, as for open I would have guessed that the three argument form of
** > ** open() would be the best solution (given the fact that a program is to
** > ** open a file passed from the outside as string; I don't know whether you
** > ** were referring to this though).
** >
** > See, you are proving my point.
**
** I don't know whether you realized, but it wasn't me you were disagreeing
** with. Not yet at least. ;-)
**
** > Validating the data is the answer, don't
** > get lured in the false sense of security "don't use string eval", "use
** > the three arg form of open".
** >
** > open my $fh, ">", $file
** >
** > is as unsafe as
** >
** > eval $str
** >
** > After all, $file could contain "/vmunix", or where ever you happen to
** > have your kernel.
**
** But this is a particularly unhelpful example. Usually the
** file-permissions take care of that. So in a low-privilege context like
** CGI this is impossible (unless configuration is borked).
But the example against eval is always the "system 'rm -rf /'".
Of course, CGI programs typically have access to files that are
important for themselves, for instances data they collect.
** It's easier to do harm with eval:
**
** my $string = "fork while 1";
** eval $string;
**
** The above brings down the system even when run as nobody or whatsoever
** unless ulimits are set (which might not be the case for a webserver
** spawning children). You can't do it with open() as you seemed to imply.
That's a bit unfair isn't? open() is safe because the servers
configuration takes care of it, but eval isn't, because other
configuration isn't set.
** > ** It's a little more difficult with string-eval. I couldn't off-hand come
** > ** up with a good methodology to sanitize any input there.
** >
** > IIRC, the OP asked about operators. I don't know about your Perl, but my
** > Perl has a small set of operators. It wouldn't be hard to test whether
** > a specific string contains an operator, and nothing but an operator.
**
** Really? Well, perlfunc lists the following numeric functions (I would
** count those as operators):
**
** "abs", "atan2", "cos", "exp", "hex", "int", "log",
** "oct", "rand", "sin", "sqrt", "srand"
**
** All of them can be arbitrarily deeply nested inside each other. A regex
** matching only the good input and throwing away the garbage is quite
** certainly above the head of the OP.
One can safely do the validation tests without even knowing regexes.
I certainly wouldn't do it with a regex. A hash, or even 'eq' will do.
And sure, one can nest those functions in many, many ways. But that
wasn't at all what the OP was asking. But suppose the OP wanted to
do that. Now, without string eval, he would have to parse the data,
otherwise you can't calculate the outcome. Guess what? You need to
do the same with string eval. Except that with string eval, you only
need to parse and validate, instead of parse and execute, because
Perl will do the execution for you. The parsing isn't going to be
any harder or easier if you want to simulate the eval yourself.
** Also, in Perl line-noise (that possibly looks as though it mostly
** consists of operators) can be a valid Perl script (I think you should
** know that best considerung your notorious JAPHs).
Since "operand binop binop operand" isn't valid anyway, there's no
reason to accept anything that isn't a single binary operator.
Why not just assume the OP wanted to simulate all Perl functions?
Including 'fork'. Now it's suddenly dangerous no matter whether
you use 'eval' or write your own Perl parser and interpreter.
Abigail
--
$" = "/"; split // => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%_ = (Just => another => Perl => Hacker); &{%_};
------------------------------
Date: 10 Feb 2003 00:29:51 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Perl operators in variables
Message-Id: <b26rpv$jtm$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
> Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
> MMMCDXLIX September MCMXCIII in <URL:news:b26nad$h68$1@nets3.rz.RWTH-Aachen.DE>:
[ opening /vmunix for writing ]
> ** But this is a particularly unhelpful example. Usually the
> ** file-permissions take care of that. So in a low-privilege context like
> ** CGI this is impossible (unless configuration is borked).
>
> But the example against eval is always the "system 'rm -rf /'".
Oh, I can already sing it! One reason why I preferred the fork-bomb this
time.
> Of course, CGI programs typically have access to files that are
> important for themselves, for instances data they collect.
Yes, this is true. And this is the reason why even open() is an
operation that needs attention under circumstances. This is not new so I
would also argue that even opening a file supplied by a user can be
dangerous.
> ** It's easier to do harm with eval:
> **
> ** my $string = "fork while 1";
> ** eval $string;
> **
> ** The above brings down the system even when run as nobody or whatsoever
> ** unless ulimits are set (which might not be the case for a webserver
> ** spawning children). You can't do it with open() as you seemed to imply.
>
> That's a bit unfair isn't? open() is safe because the servers
> configuration takes care of it, but eval isn't, because other
> configuration isn't set.
You cannot put it on one level. For open() the cases that you have to
guard against are extremely limited. For eval() anything is potentially
harmful.
> ** Really? Well, perlfunc lists the following numeric functions (I would
> ** count those as operators):
> **
> ** "abs", "atan2", "cos", "exp", "hex", "int", "log",
> ** "oct", "rand", "sin", "sqrt", "srand"
> **
> ** All of them can be arbitrarily deeply nested inside each other. A regex
> ** matching only the good input and throwing away the garbage is quite
> ** certainly above the head of the OP.
>
> One can safely do the validation tests without even knowing regexes.
> I certainly wouldn't do it with a regex. A hash, or even 'eq' will do.
Nested structures with a hash or 'eq'? I wouldn't quite know how to do
that.
> And sure, one can nest those functions in many, many ways. But that
> wasn't at all what the OP was asking.
I know, this was a slightly polemic example I deliberately used. But no
less polemic than your analogy to using split() inappropriately
somewhere else in this thread.
> But suppose the OP wanted to do that. Now, without string eval, he
> would have to parse the data, otherwise you can't calculate the
> outcome. Guess what? You need to do the same with string eval. Except
> that with string eval, you only need to parse and validate, instead of
> parse and execute, because Perl will do the execution for you. The
> parsing isn't going to be any harder or easier if you want to simulate
> the eval yourself.
But for the limited input he intends to allow, both would come very
close. Your suggestion was to check for binary operators. Anything else
is rejected. Parsing "OPRND1 OP OPRND2" and delegeting the parsed
elements to a closure or so isn't that hard either.
In this thread you argued that not telling the OP about string-eval()
would possibly exclude him from some valuable Perl-techniques. I totally
agree. But not telling him about a different solution (like using a
dispatch-table or so) will do the same, perhaps to an even bigger
extent.
I entered the thread a little too late to add yet another reply to the
OP. Had I been earlier, I would have probably mentioned eval() as well,
along with some pitfalls one has to know. Besides that, I might have
mentioned some other ways to do it.
> ** Also, in Perl line-noise (that possibly looks as though it mostly
> ** consists of operators) can be a valid Perl script (I think you should
> ** know that best considerung your notorious JAPHs).
>
> Since "operand binop binop operand" isn't valid anyway, there's no
> reason to accept anything that isn't a single binary operator.
>
> Why not just assume the OP wanted to simulate all Perl functions?
> Including 'fork'. Now it's suddenly dangerous no matter whether
> you use 'eval' or write your own Perl parser and interpreter.
True. I think no one would even consider parsing that oneself. That's
where eval() comes into the game (just because no other sensible option
exists to my knowledge), perhaps decorated with the Safe module.
I am a little lost in this thread now especially since we don't disagree
as much as the thread suggests. Your attitude: Even a newbie should be
allowed to use whatever feature Perl offers; one is as good as the
other since they all can be dangerous to some extent so we don't need to
put up a warning sign either. That's extremely liberal (a little bit
like your home-country perhaps). My attitude: A newbie can use all of
Perl but it's advisory to put up a non-mandatory warning since some
things are a little more dangerous than others; he's free to ignore it
if he so wishes.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 10 Feb 2003 07:06:38 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Perl operators in variables
Message-Id: <orje4v0ku34kcb2488l42bva3b808s5tmq@4ax.com>
Abigail wrote:
> open my $fh, ">", $file
>
>is as unsafe as
>
> eval $str
>
>After all, $file could contain "/vmunix", or where ever you happen to
>have your kernel.
You shouldn't run just any code as root.
--
Bart.
------------------------------
Date: Mon, 10 Feb 2003 09:19:15 -0500
From: "James R. Allen II" <jamesrallen@att.com>
Subject: Re: Perl operators in variables
Message-Id: <b28a9v$gc63@kcweb01.netnews.att.com>
> Yes, you are right. The user can enter the same for any other data, too.
But
> if I the program tries to e.g. multiply that malicious code then you just
> receive the wrong result. It may cause the program to fail, but usually it
> doesn't cause quite as much harm as if the data is executed as code in
eval.
"usually" would not satisfy my security team.
> In so far eval is in a risk class of it's own.
> With proper analysis of the data before submitting it to eval this is not
a
> problem. Right. But who does that analysis, in particular which beginner
> would do it when he isn't even aware that there is a potential risk?
>
> In so far I think the warnings about eval are justified. People who know
how
> to use eval sensibly don't need to ask here how to use it.
ALL user entered data is equally dangerous, whether you've ever used eval or
not. (Thinking this way keeps me sane.)
Whether a programmer has ever used a particular function before or not is
not necessarily
an indication of his skill level. I've written lots of commercial code and
have never needed to
use eval until now.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 4538
***************************************
