[15453] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 2863 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 25 18:15:33 2000

Date: Tue, 25 Apr 2000 15:15:20 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <956700920-v9-i2863@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Tue, 25 Apr 2000     Volume: 9 Number: 2863

Today's topics:
    Re: Security: why no '.' in path? <rootbeer@redcat.com>
    Re: Security: why no '.' in path? (Tad McClellan)
    Re: Set breakpoints in .perldb <rootbeer@redcat.com>
        Sorting large files via Unix system call (Andrew Krieg)
    Re: Sorting large files via Unix system call <rootbeer@redcat.com>
    Re: Sorting large files via Unix system call <lr@hpl.hp.com>
    Re: Sorting large files via Unix system call (Andrew Krieg)
    Re: Sorting large files via Unix system call (Andrew Krieg)
    Re: system return code problem (Greg Andrews)
    Re: system return code problem (Charles DeRykus)
    Re: using CPAN: what's all this junk!? (Tad McClellan)
        Win98 Pipe problem bennyboy00@my-deja.com
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Tue, 25 Apr 2000 12:57:05 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Security: why no '.' in path?
Message-Id: <Pine.GSO.4.10.10004251243280.25963-100000@user2.teleport.com>

On Tue, 25 Apr 2000 jlamport@calarts.edu wrote:

> Okay, I've been reading the CGI security FAQs, and there's one
> recommendation that I'm not sure I understand:  

Hmm. Sounds as if you have a question about CGI programming, rather than
about Perl. Perhaps you should be checking with a newsgroup about CGI
programming, such as comp.infosystems.www.authoring.cgi, but I'll see what
I can do here.

> why is it bad to have the current directory in the search path?

Mostly, this applies when running under a different user-id than the
original user, including most webserver configurations. (And it's not
really about the "current directory", but about the insecurity of using
any relative paths to find programs.)

Say your program will run the 'hostname' command. I could make my own
'hostname' command, and put it in a directory of my own choosing, where it
could be found along the path. Now, your program runs my program which
could give a false hostname. Or it could read or write something that my
user-id shouldn't be allowed to do. Or it could do even worse damage,
depending upon the situation.

> And does this only apply to the path, or to @INC as well?

Both, since I could make my own 'strict.pm', say. Of course, '.' would
normally be at the far end of either list of searchable places, so that
simple attempt would probably fail.

> I mean, the directory in which the current script is running is
> *obviously* one that I'm not going to let random people write to.

That's not obvious to me! But you do know that the CGI spec doesn't
specify which directory will be the current working directory when a CGI
program is run, right? So a CGI program which uses relative paths before
chdir'ing to an absolute location is in a state of sin.

Cheers!

-- 
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



------------------------------

Date: Tue, 25 Apr 2000 13:48:51 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: Security: why no '.' in path?
Message-Id: <slrn8gbmk3.5pk.tadmc@magna.metronet.com>

On Tue, 25 Apr 2000 17:42:06 GMT, jlamport@calarts.edu <jlamport@calarts.edu> wrote:

>Okay, I've been reading the CGI security FAQs, and there's one
>recommendation that I'm not sure I understand:  why is it bad to have the
>current directory in the search path?  


Because the Bad Guys can use that to get you to run _their_
programs with _your_ userID.

It is particularly bad if dot is first in the PATH, 'cause
then a BadGuy program named 'ls' is pretty likely to eventually
be run instead of the intended /bin/ls.

Even if it is last, they might try using a mistyped command
name (e.g. gerp (grep) or sl (ls)) which will run when you 
make a typo.


>And does this only apply to the
>path, or to @INC as well?  I mean, the directory in which the current
>script is running is *obviously* one that I'm not going to let random
                                           ^^^^^^^^^^^^^^^^^^^^

And you never ever make a mistake?

And, a cracker (having gotten root) would never install backdoors 
so he can come back again even after being found out?

And, since the current directory for CGI programs is not
standardized, you might not even _know_ what directory
you are in, unless you do a chdir() to an absolute path.
(and if you forget to chdir() in even one CGI program, you
 run the cracker's program for them).


>people write to.  So why is it any more dangerous to search in '.' than
>in any other part of the system?


Because the sysadmin should be keeping close watch on the files
in the PATH dirs, but cannot maintain that vigilance for every
single directory in the filesystem.


Having dot in the path makes life easier for crackers, not
something most people want to do  :-)


-- 
    Tad McClellan                          SGML Consulting
    tadmc@metronet.com                     Perl programming
    Fort Worth, Texas


------------------------------

Date: Tue, 25 Apr 2000 12:33:15 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Set breakpoints in .perldb
Message-Id: <Pine.GSO.4.10.10004251214470.25963-100000@user2.teleport.com>

On 25 Apr 2000, Klaus Zeitler wrote:

> I'm using perl5db (+emacs) to debug a few perl scripts. Found a few
> hints but not much information in the docu about a config file
> .perldb. Is there a way to set breakpoints so that I don't have to
> define them every time I start debugging? Can I write a history file
> and reexcute this file?

Probably, but after reading the docs and doing some experimenting, I can't
figure out how. :-P

But I know some ways to set up some "permanent breakpoints". One is to set
$DB::single to one. That'll stop at the next statement. Of course, you
could write arbitrary code to decide whether or not to set it. Does that
do anything for you?

Cheers!

-- 
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



------------------------------

Date: 25 Apr 2000 14:28:04 -0500
From: krieg@earth.execpc.com (Andrew Krieg)
Subject: Sorting large files via Unix system call
Message-Id: <3905f1c5$0$63041@news.execpc.com>

I have a large file that I need sorted.  I used a system call to perform the
sort, but the output it generated shows that the file is not getting completely
read.  The output includes 1 truncated entry, and is missing all of the rest of
the entries that were after the truncated one in the original file.

The file is 5.67 Megabytes and the Perl program loses the last 33 lines or so
(can't be more than 10K).  Is this number (5.67 Mb) close to some max buffer
size?  Is there a way to increase it?  My environment is Perl 5.004_004 for
sun4_solaris.
-- 
=__  __ __ _ __ _=  Andrew Krieg - Software Engineering Consultant        =
=_ __ _ __ _ _ __=  E-mail: retrogamer@mail.com                           =
=_    _    _  ___=  WWW:    http://www.execpc.com/~krieg		  =
=_ __ _ __ _ __ _=  Treguna  Mekoides  Trecorum  Satis  Dee  - Astoroth   =


------------------------------

Date: Tue, 25 Apr 2000 13:12:42 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Sorting large files via Unix system call
Message-Id: <Pine.GSO.4.10.10004251308470.25963-100000@user2.teleport.com>

On 25 Apr 2000, Andrew Krieg wrote:

> I have a large file that I need sorted.  I used a system call to perform the
> sort, but the output it generated shows that the file is not getting completely
> read.  

What system call? Did you use system() to call the Unix 'sort' program? Of
course, if that sort isn't doing its job, that's not Perl's fault!

> The output includes 1 truncated entry, and is missing all of the rest of
> the entries that were after the truncated one in the original file.

I think there's a limitation to the line length on some Unix sort
commands. Could that be what you're seeing? Perhaps you should ask your
vendor.

Good luck with it!

-- 
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



------------------------------

Date: Tue, 25 Apr 2000 13:14:16 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Sorting large files via Unix system call
Message-Id: <MPG.136f9c6fcb7d21ee98a978@nntp.hpl.hp.com>

In article <3905f1c5$0$63041@news.execpc.com> on 25 Apr 2000 14:28:04 -
0500, Andrew Krieg <krieg@earth.execpc.com> says...
> I have a large file that I need sorted.  I used a system call to perform the
> sort, but the output it generated shows that the file is not getting completely
> read.  The output includes 1 truncated entry, and is missing all of the rest of
> the entries that were after the truncated one in the original file.

If you are using a call to an external sort command for an existing 
input file, Perl needn't read the input file at all.  You just hand the 
file name to the command.

If you are generating the data to be sorted within your Perl program, 
rather than writing a file to be sorted externally, you might consider 
using the sort() function.  Techniques are available to make the sorting 
relatively efficient.  See:

<URL:http://www.hpl.hp.com/personal/Larry_Rosler/sort/>

> The file is 5.67 Megabytes and the Perl program loses the last 33 lines or so
> (can't be more than 10K).  Is this number (5.67 Mb) close to some max buffer
> size?  Is there a way to increase it?  My environment is Perl 5.004_004 for
> sun4_solaris.

5.67 Mb isn't so large a file, and there is no reason for Perl to lose 
any part of the data.  If you run out of memory while reading the file 
into an array, the program should terminate with an error. 

-- 
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com


------------------------------

Date: 25 Apr 2000 16:10:39 -0500
From: krieg@earth.execpc.com (Andrew Krieg)
Subject: Re: Sorting large files via Unix system call
Message-Id: <390609d0$0$46093@news.execpc.com>

In article <Pine.GSO.4.10.10004251308470.25963-100000@user2.teleport.com>,
Tom Phoenix  <rootbeer@redcat.com> wrote:
>On 25 Apr 2000, Andrew Krieg wrote:
>
>> I have a large file that I need sorted.  I used a system call to perform the
>> sort, but the output it generated shows that the file is not getting completely
>> read.  
>
>What system call? Did you use system() to call the Unix 'sort' program? Of
>course, if that sort isn't doing its job, that's not Perl's fault!

Yes, I used the Perl system to call Unix 'sort'.  I also tried Perl's exec to
call the Unix command.  Both behaved the same.  The Unix sort command I am
using works fine on the command line for this data file.  It is only when
calling it from Perl that problems occurs.

>> The output includes 1 truncated entry, and is missing all of the rest of
>> the entries that were after the truncated one in the original file.
>
>I think there's a limitation to the line length on some Unix sort
>commands. Could that be what you're seeing? Perhaps you should ask your
>vendor.

This line is no longer than any of the others.  There are longer lines in the
file.

One other strange thing that happens when running the sort via Perl, the input
data file is modified!  An extra blank line is added to the end of the file.

>Good luck with it!

Thanks, we're still digging.

-- 
=__  __ __ _ __ _=  Andrew Krieg - Software Engineering Consultant        =
=_ __ _ __ _ _ __=  E-mail: retrogamer@mail.com                           =
=_    _    _  ___=  WWW:    http://www.execpc.com/~krieg		  =
=_ __ _ __ _ __ _=  Treguna  Mekoides  Trecorum  Satis  Dee  - Astoroth   =


------------------------------

Date: 25 Apr 2000 16:34:31 -0500
From: krieg@earth.execpc.com (Andrew Krieg)
Subject: Re: Sorting large files via Unix system call
Message-Id: <39060f68$0$19893@news.execpc.com>

Argh!  Problem solved.  Some other processing was done on the file prior to the
sort and the programmer (not me, honest!) forgot to close the file in Perl.
Thanks for the helpful e-mails!

In article <3905f1c5$0$63041@news.execpc.com>,
Andrew Krieg <krieg@earth.execpc.com> wrote:
>I have a large file that I need sorted.  I used a system call to perform the
>sort, but the output it generated shows that the file is not getting completely
>read.  The output includes 1 truncated entry, and is missing all of the rest of
>the entries that were after the truncated one in the original file.
>
>The file is 5.67 Megabytes and the Perl program loses the last 33 lines or so
>(can't be more than 10K).  Is this number (5.67 Mb) close to some max buffer
>size?  Is there a way to increase it?  My environment is Perl 5.004_004 for
>sun4_solaris.

-- 
=__  __ __ _ __ _=  Andrew Krieg - Software Engineering Consultant        =
=_ __ _ __ _ _ __=  E-mail: retrogamer@mail.com                           =
=_    _    _  ___=  WWW:    http://www.execpc.com/~krieg		  =
=_ __ _ __ _ __ _=  Treguna  Mekoides  Trecorum  Satis  Dee  - Astoroth   =


------------------------------

Date: 25 Apr 2000 11:13:54 -0700
From: gerg@shell.ncal.verio.com (Greg Andrews)
Subject: Re: system return code problem
Message-Id: <8e4n92$buj$1@shell1.ncal.verio.com>

Al Bundy <AlBundy@aol.net> writes:
>I am trying to execute a system call such as:
>
>system( "myprogram | tee afile.log" );
>
>In a Unix shell, executing "myprogram | tee afile.log" always
>returns the exit status of myprogram, which is what I desire.
>

In my experience, the exit code of a pipeline does NOT come
from the first command in the pipeline.

In fact, the Solaris 2.6 man page for sh has this to say about
pipelines:

     A pipeline is a sequence of one or more  commands  separated
     by  |.   The standard output of each command but the last is
     connected by a pipe(2) to the standard  input  of  the  next
     command.   Each  command  is  run as a separate process; the
     shell waits for the last command  to  terminate.   The  exit
     status  of a pipeline is the exit status of the last command
     in the pipeline.

See that last sentence?  The exit code comes from the last command
in the pipeline, not the first.

This is consistent with the test results you posted.

If you want to have the output of the first command go to stdout
and a file, yet capture the first command's exit code instead of
the exit code from tee, then perform the tee function in your
Perl script.  I've done similar things in my scripts.

  -Greg
-- 
:::::::::::::::::::  Greg Andrews  gerg@wco.com  :::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


------------------------------

Date: Tue, 25 Apr 2000 20:45:07 GMT
From: ced@bcstec.ca.boeing.com (Charles DeRykus)
Subject: Re: system return code problem
Message-Id: <FtLAz7.KIp@news.boeing.com>

In article <f1lbgscrc1cfmdu5j1tcpjog1s88nguhcn@4ax.com>,
Al Bundy  <AlBundy@aol.net> wrote:
>I am trying to execute a system call such as:
>
>system( "myprogram | tee afile.log" );
>...
>When I do this in Perl 5, forcing a return code of 127 in myprogram,
>the above  system call returns 0.
>
>If I remove the "| tee afile.log" from the system command, the
>return value is as expected, 32512.  (127 * 256).
>
>Any ideas on how to get around this?  I can not simply add
>"> afile.log" to the command due to other requirements.
>

Perhaps, a kludge:  

system q{ (myprogram;sv=$?) | tee afile.log;exit $sv };

--
Charles DeRykus



------------------------------

Date: Tue, 25 Apr 2000 13:52:57 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: using CPAN: what's all this junk!?
Message-Id: <slrn8gbmrp.5pk.tadmc@magna.metronet.com>

On Tue, 25 Apr 2000 17:32:22 GMT, jlamport@calarts.edu <jlamport@calarts.edu> wrote:

>though if
>anyone has any tips/warnings about installing modules for use in a user
>account, I'm sure I and others on this list could benefit from the
          ^^^^^^^^^^^^^^^^^^^^^              ^^^^^^^^^^^^^
>knowlege...


That might imply that your Question is Asked Frequently.


   perldoc -q module

   "How do I keep my own module/library directory?"


-- 
    Tad McClellan                          SGML Consulting
    tadmc@metronet.com                     Perl programming
    Fort Worth, Texas


------------------------------

Date: Tue, 25 Apr 2000 20:23:29 GMT
From: bennyboy00@my-deja.com
Subject: Win98 Pipe problem
Message-Id: <8e4urj$u0n$1@nnrp1.deja.com>

While encountering errors using pipes and Windows 98 we tried this
simple program:

#!/usr/local/bin/perl
open (Reader, "dir|");
while (<Reader>){
   print $_."\n";
}

This works fine on Windows NT, but it hangs forever in Windows 98
printing nothing.

Any suggestions for how to get pipes working in win98?

Thanks,
~Ben


Sent via Deja.com http://www.deja.com/
Before you buy.


------------------------------

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.  

| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

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 V9 Issue 2863
**************************************


home help back first fref pref prev next nref lref last post