[31838] in Perl-Users-Digest
Perl-Users Digest, Issue: 3101 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 26 18:14:24 2010
Date: Thu, 26 Aug 2010 15:14:12 -0700 (PDT)
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, 26 Aug 2010 Volume: 11 Number: 3101
Today's topics:
Re: Writing or copying file to another directory <tadmc@seesig.invalid>
Re: Writing or copying file to another directory <tadmc@seesig.invalid>
Re: Writing or copying file to another directory <stevem_@nogood.com>
Re: Writing or copying file to another directory <ben@morrow.me.uk>
Re: Writing or copying file to another directory <ben@morrow.me.uk>
Re: Writing or copying file to another directory <stevem_@nogood.com>
Re: Writing or copying file to another directory (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 26 Aug 2010 13:57:45 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Writing or copying file to another directory
Message-Id: <slrni7de0m.6po.tadmc@tadbox.sbcglobal.net>
Paul E. Schoen <paul@pstech-inc.com> wrote:
> "Ben Morrow" <ben@morrow.me.uk> wrote in message
> news:jeggk7-7hb2.ln1@osiris.mauzo.dyndns.org...
>>
>>
>> Where is
>>
>> use warnings;
>> use strict;
>
> It works with warnings, but strict causes it to fail
Then modify the program so that strict does cause it to fail.
If you have questions about how to modify the program so that strict
does not cause it to fail, then post a question about modifying your
program so that strict will not cause it to fail.
>>> %in= &getcgivars ;
>>
>> Don't call subs with '&'.
>
> It did not work when I removed the &
Use parens on the end instead of ampersand at the front:
my %in = getcgivars();
(But you should throw that code you got from the Web into the trash
where it belongs, and use a proper module for accessing form values.
)
You can replace it easily, as suggested in one of the answers to the
FAQs quoted below.
use CGI 'Vars';
...
my %in = Vars();
>>> open(MAIL, "|$mailprog $recipient")
>>> || &HTMLdie("Couldn't send the mail (couldn't run $mailprog).") ;
>>
>> Use multi-arg open.
>> Use lexical filehandles.
>>
>> open(my $MAIL, "|-", $mailprog, $recipient)
>> || HTMLdie("...");
>
> It does not work with "my".
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
What did you observe that led you to believe that it did not work?
We are generally not very good at mind reading...
Did it fail to run?
Did it run but made the wrong output?
Did it issue any messages?
Did it make smoke come out of your computer's vents?
Did it start a global thermonuclear war?
>>> close(MAIL) ;
>>
>> You are writing to MAIL, so you need to check the return value of close.
>
> Yes, that is good practice. I will need to check the details of the
> function.
Good idea.
> Boolean?
Checking the details of the function should enable you to answer
that question without being dependent on others:
perldoc -f close
>>> #chdir('/home/pstech/www/SCGBG/'); #still writes to cgi-bin
>>
>> Does this directory exist? Can the CGI process see it? Is the CGI
>> process running chrooted?
>
> The directory exists and I can go there
But your CGI program is most likely not running as you, so what
you can do is not relevant.
What is relevant is what the user that your CGI program runs as
(often "nobody" or "www" or somesuch, it depends on how your web
server was setup) can do.
> using Telnet "cd
> /home/pstech/www/SCGBG/". I don't know what "chrooted" means.
http://lmgtfy.com/?q=chroot
> I need to learn more about how to debug a script.
As with most things, you start with the Frequently Asked Questions:
perldoc -q debug
How do I debug my Perl programs?
> The
> error messages were very helpful. But I'm not sure if I can run the mailer
> script from Telnet.
It is not relevant whether or not you can run it.
What is relevant is what the user that your CGI program runs as
(often "nobody" or "www" or somesuch, it depends on how your web
server was setup) can do.
> Is there a way to see the compiler error messages,
> perhaps in an error log?
As with most things, you start with the Frequently Asked Questions:
perldoc -q CGI
How can I make my CGI script more efficient?
Where can I learn about CGI or Web programming in Perl?
What is the correct form of response from a CGI script?
My CGI script runs from the command line but not the browser.
(500 Server Error)
===> How can I get better error messages from a CGI program?
How do I make sure users can't enter values into a form that
cause my CGI script to do bad things?
How do I decode a CGI form?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 26 Aug 2010 14:03:59 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Writing or copying file to another directory
Message-Id: <slrni7decd.6po.tadmc@tadbox.sbcglobal.net>
Paul E. Schoen <paul@pstech-inc.com> wrote:
> If I use the normal URL:
>
> http://www.smart.net/~pstech/cgi-bin/TestCopy.pl
>
> I just get the text of the TestCopy.pl script.
This is very very bad.
Bad People can do Bad Things even without seeing the code that is
being run.
Giving them access to the code, makes it even easier for them to crack
your site.
If you don't want to suffer an attack, you should contact your
provider and figure out how to get them to stop doing that.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 26 Aug 2010 12:34:57 -0500
From: Steve <stevem_@nogood.com>
Subject: Re: Writing or copying file to another directory
Message-Id: <9nzdo.96109$xZ2.84646@newsfe07.iad>
On 08/26/2010 01:57 PM, Tad McClellan wrote:
>>>> #chdir('/home/pstech/www/SCGBG/'); #still writes to cgi-bin
>>>
>>> Does this directory exist? Can the CGI process see it? Is the CGI
>>> process running chrooted?
>>
>> The directory exists and I can go there
>
>
> But your CGI program is most likely not running as you, so what
> you can do is not relevant.
>
Ummm.... if it is NOT running scripts as the site owner/user, then the
web server is not running SUEXEC.
That in itself is a huge red flag, since anyone on the server can access
his scripts, and more importantly, any authentication values in the
scripts or in configuration files.
In other words, Paul's scripts have no security at all......
Personally, I would never even consider doing CGI on a shared server
that was not running SUEXEC.
my $.02
It's been a few years since I used it, but I believe the below might
tell Paul if the server is running SUEXEC:
#!/usr/bin/perl
use warnings;
use strict;
my $real_uid = $<;
my $uid_name = getpwuid($real_uid);
my $effective_uid = $>;
my $eff_name = getpwuid( $effective_uid );
my $real_group = $(;
my $group_name = getgrgid($real_group);
my $effective_group = $);
my $eff_group = getgrgid( $effective_group );
print "Content-type: text/plain\n\n";
print qq~
Real User: $real_uid / $uid_name
Process User: $effective_uid / $eff_name
Real Group: $real_group / $group_name
Process Group: $effective_group / $eff_group
~;
The output(s) should match... on my local box I get this:
Real User: 502 / testuser
Process User: 502 / testuser
Real Group: 416 416 / apache
Process Group: 416 416 / apache
If Real User and Process User do NOT match... well...
\s
------------------------------
Date: Thu, 26 Aug 2010 21:09:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Writing or copying file to another directory
Message-Id: <39uik7-4cp2.ln1@osiris.mauzo.dyndns.org>
Quoth Steve <stevem_@nogood.com>:
>
> Ummm.... if it is NOT running scripts as the site owner/user, then the
> web server is not running SUEXEC.
>
> That in itself is a huge red flag, since anyone on the server can access
> his scripts, and more importantly, any authentication values in the
> scripts or in configuration files.
(To my mind CGI is in and of itself a security hole. I always use
FastCGI, now, with an independantly-stared FastCGI-process running as a
dedicated user...)
> In other words, Paul's scripts have no security at all......
>
> Personally, I would never even consider doing CGI on a shared server
> that was not running SUEXEC.
>
> my $.02
>
> It's been a few years since I used it, but I believe the below might
> tell Paul if the server is running SUEXEC:
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> my $real_uid = $<;
> my $uid_name = getpwuid($real_uid);
>
> my $effective_uid = $>;
> my $eff_name = getpwuid( $effective_uid );
No. This will tell you if you are running setid; but suEXEC does a
'full' setid setting both real and effective IDs, so you won't see it.
(Incidentally, this means perl won't turn on taint mode for you. Make
sure to remember to do that yourself.)
You need to check if $> is your uid, or the webserver's.
Ben
------------------------------
Date: Thu, 26 Aug 2010 21:10:35 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Writing or copying file to another directory
Message-Id: <rauik7-4cp2.ln1@osiris.mauzo.dyndns.org>
Quoth Tad McClellan <tadmc@seesig.invalid>:
>
> This is very very bad.
>
> Bad People can do Bad Things even without seeing the code that is
> being run.
>
> Giving them access to the code, makes it even easier for them to crack
> your site.
I think the Open Source movement might have an issue with this
assertion...
Ben
------------------------------
Date: Thu, 26 Aug 2010 13:39:03 -0500
From: Steve <stevem_@nogood.com>
Subject: Re: Writing or copying file to another directory
Message-Id: <fjAdo.30735$6o7.20335@newsfe21.iad>
On 08/26/2010 03:09 PM, Ben Morrow wrote:
>
> Quoth Steve<stevem_@nogood.com>:
>>
>> Ummm.... if it is NOT running scripts as the site owner/user, then the
>> web server is not running SUEXEC.
>>
>> That in itself is a huge red flag, since anyone on the server can access
>> his scripts, and more importantly, any authentication values in the
>> scripts or in configuration files.
>
> (To my mind CGI is in and of itself a security hole. I always use
> FastCGI, now, with an independantly-stared FastCGI-process running as a
> dedicated user...)
>
>> In other words, Paul's scripts have no security at all......
>>
>> Personally, I would never even consider doing CGI on a shared server
>> that was not running SUEXEC.
>>
>> my $.02
>>
>> It's been a few years since I used it, but I believe the below might
>> tell Paul if the server is running SUEXEC:
>>
>> #!/usr/bin/perl
>>
>> use warnings;
>> use strict;
>>
>> my $real_uid = $<;
>> my $uid_name = getpwuid($real_uid);
>>
>> my $effective_uid = $>;
>> my $eff_name = getpwuid( $effective_uid );
>
> No. This will tell you if you are running setid; but suEXEC does a
> 'full' setid setting both real and effective IDs, so you won't see it.
> (Incidentally, this means perl won't turn on taint mode for you. Make
> sure to remember to do that yourself.)
>
> You need to check if $> is your uid, or the webserver's.
>
> Ben
>
As I say, it's been a number of years since I used that code, but as I
recalled, on a non-SUEXEC Apache setup, it would return different user
names, and the same on SUEXEC.
A quick test shows that you are right and my memory was faulty. (surpirse)
At any rate it will tell you who the CGI is running as....
The *same* virtual host with SUEXEC
Real User: 502 / testuser
Process User: 502 / testuser
Real Group: 416 416 / apache
Process Group: 416 416 / apache
And then without SUEXEC:
Real User: 480 / apache
Process User: 480 / apache
Real Group: 416 416 / apache
Process Group: 416 416 / apache
So... I guess it would be more accurate to say that if the Real and
Process user is the owner of the script as opposed to Apache, then
SUEXEC is turned on/enabled.
thanks for looking over my shoulder Ben.
\s
------------------------------
Date: Thu, 26 Aug 2010 13:31:50 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Writing or copying file to another directory
Message-Id: <867hjdw1xl.fsf@red.stonehenge.com>
>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
Ben> I think the Open Source movement might have an issue with this
Ben> assertion...
Nope. The Open Source movement says the same thing. If bad guys can
see the source, they can break it easier.
The Open Source movement offsets this with, "but if the good guys can
also see it, and FIX it, then the risk is appropriately mitigated."
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3101
***************************************
