[22341] in Perl-Users-Digest
Perl-Users Digest, Issue: 4562 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 13 06:11:49 2003
Date: Thu, 13 Feb 2003 03:10:09 -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 Thu, 13 Feb 2003 Volume: 10 Number: 4562
Today's topics:
Re: Request help with this script <peakpeek@purethought.com>
Re: Request help with this script (Julia Briggs)
Re: Request help with this script <bart.lateur@pandora.be>
Re: Request help with this script (Jay Tilton)
Re: Saving/Editing SQL queries (Guy)
Re: strict and warnings (Helgi Briem)
Re: strict and warnings (Anno Siegel)
Re: Syntax error <jurgenex@hotmail.com>
Re: Using a variable to create a slice (Tad McClellan)
Using Archive::Tar for in-memory tarfiles <eric.schwartz@hp.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Feb 2003 04:53:08 +0000
From: Sharon Grant <peakpeek@purethought.com>
Subject: Re: Request help with this script
Message-Id: <pu8m4v8ic9jm6l4purav39rohthco3301s@4ax.com>
On Tue, 11 Feb 2003 06:50:50 GMT, in comp.lang.perl.misc, tiltonj@erols.com (Jay Tilton) wrote:
>julia4_me@yahoo.com (Julia Briggs) wrote:
>
>: open(MAIL, "| $mailprog -t ");
>
>More harmful but equally trivial, a person can use this code to run
>any program he wants on your machine
Can you explain this statement please?
--
Sharon
------------------------------
Date: 12 Feb 2003 23:24:38 -0800
From: julia4_me@yahoo.com (Julia Briggs)
Subject: Re: Request help with this script
Message-Id: <c48f65ef.0302122324.4792925a@posting.google.com>
Thanks, you are very helpful!! :)) I am wondering, how can I add a
little routine to this script that blocks people from loading the .pl
script directly in their browser, thereby reading the code within and
sends them to a warning screen instead? Is there any possible way
around this if it was implemented, let's say if someone used a
non-traditional browser to read it?
Thanks again, Julia
tiltonj@erols.com (Jay Tilton) wrote in message news:<3e4a0933.234915868@news.erols.com>...
> julia4_me@yahoo.com (Julia Briggs) wrote:
>
> : > Do not use this code. If it is up and running, remove it immediately.
> :
> : EEP! Using the above mentioned changes, will it prevent what you are
> : speaking of here (running other programs )??
>
> Summarizing and expanding on the changes suggested by others:
>
> 1. use warnings;
>
> Mostly a debugging tool, but an invaluable one. Don't develop code
> without it.
>
> 2. use strict;
>
> That one deserves the most attention. The way the program uses
> symbolic references creates gaping holes that allow the user to change
> a lot of what goes on in the program.
>
> The other thing strict will help is that you'll have to declare the
> program's variables, encouraging use of my() instead of local().
>
> The program will need some non-trivial changes to accommodate "use
> strict;" and you will probably find it frustrating. But it will force
> changes to exactly the places where the program is most easily
> compromised.
>
> 3. Put the -T switch on the shebang line.
>
> Forcing taint checks on data encourages the habit of validating all
> incoming data before it's used for anything. You'll have to consider
> exactly what data may be considered valid. It's better to be overly
> restrictive than to be overly permissive.
>
> This is tricky. It's easy to a bad job of laundering tainted data,
> and it is not as easy to do it well. Put perlsec on your must read
> list.
>
> 4. Check the results of open() and close().
>
> Solid advice for any program, not just one that will run in a CGI
> environment. When those two functions are allowed to silently fail,
> you'll go bananas trying to find the problem.
>
> 5. Use the "function()" form of subroutine call instead of the
> "&function" one.
>
> The "&function" form has some peculiar effects. Unless you know what
> they are and you know you need them, use the "function()" form. See
> perlsub to learn more.
>
> There's also a style issue in that one. Heavy use of the "&function"
> form suggests the program is a relic of the Perl4 era, and the author
> hasn't bothered learning anything since.
>
> 6. Utilize the methods provided by CGI.pm
>
> for the HTTP response header, at least. The routine is already loaded
> with "use CGI;" , it's easy, and it can provide more flexibility than
> simply printing a Content-type.
------------------------------
Date: Thu, 13 Feb 2003 09:40:35 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Request help with this script
Message-Id: <4ipm4vo62u1stfo9lrcd1r1cdps002nkka@4ax.com>
Julia Briggs wrote:
>I am wondering, how can I add a
>little routine to this script that blocks people from loading the .pl
>script directly in their browser, thereby reading the code within and
>sends them to a warning screen instead?
That's not possible. If the server is set up right, people will *never*
see the source code. The server *runs* the code, on server side, the
user only gets back the result of the processing.
As other people said... this script is dangerous to use, becauses it
leaves open several doors for other people, like spammers, to abuse. If
they smell a possibility to abuse it, they'll find the cracks, without
ever seeing the source, just by experimenting.
I assume the receiver of the email could be any address, passed as a
form parameter? That has to go. Limit the recipients to a list, known in
the script, and refuse to send anything to any other address. For a
start. Don't pass the email address through the form, that'll reduce the
chance of people even trying. Use a code, which the recipient can look
up in its list. A code with a built-in checksum is better still.
And that's just one point.
--
Bart.
------------------------------
Date: Thu, 13 Feb 2003 10:40:56 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: Request help with this script
Message-Id: <3e4b723f.327357967@news.erols.com>
On Thu, 13 Feb 2003 04:53:08 +0000, Sharon Grant
<peakpeek@purethought.com> wrote:
: On Tue, 11 Feb 2003 06:50:50 GMT, in comp.lang.perl.misc, tiltonj@erols.com (Jay Tilton) wrote:
:
: >julia4_me@yahoo.com (Julia Briggs) wrote:
: >
: >: open(MAIL, "| $mailprog -t ");
: >
: >More harmful but equally trivial, a person can use this code to run
: >any program he wants on your machine
:
: Can you explain this statement please?
$maillprog can be given a new value from the query parameters.
Then the piped open will run whatever program is named in $mailprog.
------------------------------
Date: 13 Feb 2003 01:34:59 -0800
From: google@glu.us (Guy)
Subject: Re: Saving/Editing SQL queries
Message-Id: <9da3ad03.0302130134.33e0c912@posting.google.com>
guymal@hotmail.com (Guy) wrote in message news:<8c80bc84.0302120041.528ae3f6@posting.google.com>...
> Hi,
> I'm working on a web application (written in Perl, duh!) that allows users
> to execute SQL queries on a relational database (and save/edit these
> queries).
> Since the users have no knowledge of either the db scheme or SQL, my
> application lets them create queries using a web based GUI according to
> terms that the users know (an abstraction of the db scheme).
>
> I'm looking for a way to translate a given data structure (that represents
> what the user wants in their query) to actual SQL (so I can run it) and to
> save this query in order to edit it later.
>
> Here is a typical scenario:
> A user creates a query using the GUI, their query is translated into SQL and
> executed. The user can save this query (somehow) and edit it later in the
> GUI (and then save it again).
>
> Any suggestions/ideas?
>
> TIA,
> Guy
Rich, the problem with your solution is that it is directly related to
the ERD. The thing is that the users have no idea what tables or
columns are in the database. All they know are abstract terms.
In order to come up with a usable GUI I already created the front end
(ie: the part the user interacts with). This ensures that I'm giving
my users a solution that is relevant to the world they know and not a
solution that requires knowledge of the database world (the ERD).
Now what I have to do is translate the things they selected (after
submitting a form) into SQL.
The data structure that is created is something like this (I am
looking for a general way to translate this into a SQL query):
$VAR1 = bless( {
'cpu_tab' => bless( {
'cpu_0_0_attribute' => 'Speed',
'cpu_0_0_operator' => 'equals',
'cpu_0_0_value' => '300 Mhz',
'cpu_0_1_between_operator' => 'and',
'cpu_0_1_attribute' => 'Model',
'cpu_0_1_operator' => 'doesn\'t equal',
'cpu_0_1_value' => 'Pentium III',
'cpu_0_2_between_operator' => 'and',
'cpu_0_2_attribute' => 'Vendor',
'cpu_0_2_operator' => 'equals',
'cpu_0_2_value' => 'Intel',
'number_of_cpus' => '2',
'cpu_1_0_attribute' => 'Speed',
'cpu_1_0_operator' => '>',
'cpu_1_0_value' => '200 Mhz',
'cpu_1_1_between_operator' => 'and',
'cpu_1_1_attribute' => 'Model',
'cpu_1_1_operator' => 'equals',
'cpu_1_1_value' => 'Pentium II',
}, 'Apache::ASP::Collection' ),
'memory_tab' => bless( {
'mem_0_attribute' => 'Frequency',
'mem_0_operator' => '>',
'mem_0_value' => '100Mhz',
'mem_1_between_operator' => 'and',
'mem_1_attribute' => 'Type',
'mem_1_operator' => 'equals',
'mem_1_value' => 'DDRAM',
'mem_2_between_operator' => 'and',
'mem_2_attribute' => 'Size',
'mem_2_operator' => 'equals',
'mem_2_value' => '32MB',
'number_of_conditions' => '3',
}, 'Apache::ASP::Collection' )
}, 'Apache::ASP::Session' );
Thanks,
Guy
------------------------------
Date: Thu, 13 Feb 2003 10:20:40 GMT
From: helgi@decode.is (Helgi Briem)
Subject: Re: strict and warnings
Message-Id: <3e4b70da.512876537@news.cis.dfn.de>
On Wed, 12 Feb 2003 20:14:56 -0500, Benjamin Goldberg
<goldbb2@earthlink.net> wrote:
>>Abigails .sig:
>>rand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]
>>for(reverse+1..(@[=split//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));
>>print+(map{$_^q^"^}@[),"\n"
>PS: Your .sig produces: "o JutPrerclrHtek naahe s" on AS Perl 5.6.1.
Not at all, it produces:
araknsrt ehuJH oe rPeltc
Then again it produces:
tueea olrJckPHer ra htsn
Oh, no! I'm getting:
rentrJ etaehkPcslu Hra o
I think the 'rand' bits may be a clue.
--
Regards, Helgi Briem
helgi AT decode DOT is
------------------------------
Date: 13 Feb 2003 10:47:03 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: strict and warnings
Message-Id: <b2ft37$r3t$3@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Abigail:
>
> > Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
> > MMMCDLII September MCMXCIII in
> <URL:news:b2d0t2$gss$1@nets3.rz.RWTH-Aachen.DE>:
> >:}
> >:} What you say is that you prefer warning messages pop up all over the
> >:} place whenever something unexpected but harmless has happened on the
> >:} internals. Unlike a "General Protection Fault", a warning is not fatal
> >:} (it has fatal consequences only sometimes).
> >
> > If a piece of code of mine produces a warning, than something I had
> > not anticipated happened. It might happen to be harmful, but that
> > would be sheer luck. I do consider that a bug. Had I antipated the
> > potential warning, and it deemed to be harmless, warnings would had
> > been turned off selectively for that section of the code.
>
> I think we are gradually moving away from the original issue. There is
> no need to argue that warnings are indispensable for the developer. What
> you describe is common for the development stage but a different
> approach might be needed when something is released. A new pragma is
> needed, 'mod_warnings' perhaps, that is a replacement for warnings in
> modules. It is the analogy of warn() <=> carp().
The new (as of 5.8.0) "lexical warnings" (perldoc lexwarn) seems to be
an attempt at that. Unfortunately the current implementation isn't
quite satisfactory. An attempt to fix it only got me lost in a maze
of alternatives and implications.
Anno
------------------------------
Date: Thu, 13 Feb 2003 04:16:30 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Syntax error
Message-Id: <y_E2a.7704$SB2.6637@nwrddc03.gnilink.net>
spyderscripts wrote:
> I get the error: Bad name after 'username' when using:
> my @unverified_emails=('$form{'usermail'}', '$ID');
>
> Anyone have suggestions on how to correct the problem?
You are trying to apply the infix operator usermail to the two string
arguments '$form{' and '}'.
That's not gone work becasue there is no operator called usermail in Perl.
I don't know what you are trying to do here.
Are you trying to define a 2-element list containing the two literal text
pieces
$form{'usermail'}
$ID
Then you need to escape the quotes around usermail:
my @unverified_emails=('$form{\'usermail\'}', '$ID');
jue
------------------------------
Date: Thu, 13 Feb 2003 00:05:40 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Using a variable to create a slice
Message-Id: <slrnb4mddk.1vq.tadmc@magna.augustmail.com>
James E Keenan <jkeen@concentric.net> wrote:
>
> "Terry Bolands" <tbolands@yahoo.com> wrote in message
> news:6393ea9a.0302121412.11235c6c@posting.google.com...
>> Hi,
>>
>> I want to do something like this:
>>
>> @array[1,2,3] = (stuff);
>>
>> with a variable like this:
>>
>> $v = "1,2,3";
>> @array[$v] = (stuff);
>>
> You can't do this.
Yes you can (but you probably shouldn't).
It puts the string 'stuff' (barewords are bad!) into $array[1].
> Inside the square brackets you can place either a single
> integer (or an expression that evaluates to an integer)
ie. a scalar.
> or a range of
> integers indicated by the range operator.
No, that should be: or "a list".
The range operator is just one way of generating a list.
> Your $v holds a string of
> characters.
Which will be DWIMed into the number 1.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 12 Feb 2003 21:08:23 -0700
From: Eric Schwartz <eric.schwartz@hp.com>
Subject: Using Archive::Tar for in-memory tarfiles
Message-Id: <etor8achlfs.fsf@wormtongue.emschwar>
I'm trying to create an in-memory tarfile (for stuffing into a BLOB)
using Archive::Tar, and seem to not be reading something in the docs
right.
Here's the code I'm using:
==========================
#!/usr/bin/perl
use warnings;
use strict;
use Archive::Tar;
my $tar = Archive::Tar->new();
$tar->add_files(@ARGV);
my $buf = $tar->write();
open(TAR, '>/tmp/tarfile.tar');
binmode(TAR);
print TAR $buf;
close(TAR);
# this is just to verify to myself that it works
$tar->write('/tmp/newtar.tar');
==========================
The problem is that when I run it, the archive contents I created in
$buf have the right name and size, but the contents are filled with 0
bytes. The archive I create with the last call to $tar->write() is
exactly correct.
What I *really* want to do is create a compressed tarfile using
Compress::Zlib, but first I think I should get the tarfile itself
working. Unless I misread it, I can't see how to use Archive::Tar's
built-in support for compressed tarfiles with in-memory archives.
I guess a quick-and-dirty solution would be to physically generate
the tarfiles on disk and then load them into memory, but that seems
rather wasteful.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
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 4562
***************************************