🚀 go-pugleaf

Hi, there !

Frank C. wrote:
> 
> I am almost ready to launch my own home page which contains an
> interactive Web spot requiring a Perl script. However my system
> administrator will not accept Perl because of the alleged security
> problems. My own research reveals that most interactive Web pages -
> approximately 80% - use Perl scripts to execute them. Thus I require
> advice on the following matters:
> 
> 1. What security hazard does Perl actually pose?
> 
> 2. How do I rectify the problem i.e. where can I get a suitable CGI
>    script?
> 
> 3. Is there anybody out there who is prepared to assist me in putting
>    together a CGI-bin script for a fee? I live in Melbourne, Australia.

 The system administrator at our local computing center also doesn't
 want users to have executed their own scripts. One problem is that
 those scripts need CPU sources (maybe somebody wants to serve
 raytraced images online ...). Another (maybe more important) fact
 is security. As an example, if you write a script using a c-shell
 that executes 'finger', you might write somthing like

      system("finger $user_input");

 But a clever remote user could type not only "asterix" to finger
 that user, but "asterix; ls -l" which will execute 'ls -l', too !
 (And 'ls -l' is rather harmless ...).

 That's why often only experienced users who know about certain
 traps are allowed to run CGI scripts on a site.

 The only solution might be to become a system administrator of
 yourself ... which I'll do in a few days ...   ;-)

 If you can convince your system admin about your programming
 experience this group may be a good place to learn about perl
 (but please post perl-related questions - there are cgi-groups,
 too).


 Bye, Eike

=====================================================================
 Eike Grote, Theoretical Physics IV, University of Bayreuth, Germany
            email : eike.grote@theo.phy.uni-bayreuth.de
         URL : http://btrzxa.fddi.uni-bayreuth.de/~btpa25/
=====================================================================

	You could also start up your own web server, if you have access to do 
that.  just make sure your port number is > 1024.  I'd suggest something with 5
digits :)
	There are security problems, because everything that is done by the
cgi program is done as the webserver user (there *are* ways around this, 
though) and on alot of systems, that's user 'nobody'...
	Brian Wheeler
	bdwheele@indiana.edu

In article <3186314C.41C6@theo.phy.uni-bayreuth.de>, 
eike.grote@theo.phy.uni-bayreuth.de says...
>
>Hi, there !
>
>Frank C. wrote:
>> 
>> I am almost ready to launch my own home page which contains an
>> interactive Web spot requiring a Perl script. However my system
>> administrator will not accept Perl because of the alleged security
>> problems. My own research reveals that most interactive Web pages -
>> approximately 80% - use Perl scripts to execute them. Thus I require
>> advice on the following matters:
>> 
>> 1. What security hazard does Perl actually pose?
>> 
>> 2. How do I rectify the problem i.e. where can I get a suitable CGI
>>    script?
>> 
>> 3. Is there anybody out there who is prepared to assist me in putting
>>    together a CGI-bin script for a fee? I live in Melbourne, Australia.
>
> The system administrator at our local computing center also doesn't
> want users to have executed their own scripts. One problem is that
> those scripts need CPU sources (maybe somebody wants to serve
> raytraced images online ...). Another (maybe more important) fact
> is security. As an example, if you write a script using a c-shell
> that executes 'finger', you might write somthing like
>
>      system("finger $user_input");
>
> But a clever remote user could type not only "asterix" to finger
> that user, but "asterix; ls -l" which will execute 'ls -l', too !
> (And 'ls -l' is rather harmless ...).
>
> That's why often only experienced users who know about certain
> traps are allowed to run CGI scripts on a site.
>
> The only solution might be to become a system administrator of
> yourself ... which I'll do in a few days ...   ;-)
>
> If you can convince your system admin about your programming
> experience this group may be a good place to learn about perl
> (but please post perl-related questions - there are cgi-groups,
> too).
>
>
> Bye, Eike
>
>=====================================================================
> Eike Grote, Theoretical Physics IV, University of Bayreuth, Germany
>            email : eike.grote@theo.phy.uni-bayreuth.de
>         URL : http://btrzxa.fddi.uni-bayreuth.de/~btpa25/
>=====================================================================

Frank

Iam a system administrator and would be happy to help anyway I can. We 
also offer full hosting services at very low prices with full cgi-bin 
access. visit our homepages at http://olm.net/

Best regards
George



Frank C. wrote:
> 
> Dear Netizens,
> 
> I am almost ready to launch my own home page which contains an
> interactive Web spot requiring a Perl script. However my system
> administrator will not accept Perl because of the alleged security
> problems. My own research reveals that most interactive Web pages -
> approximately 80% - use Perl scripts to execute them. Thus I require
> advice on the following matters:
> 
> 1. What security hazard does Perl actually pose?
> 
> 2. How do I rectify the problem i.e. where can I get a suitable CGI
>    script?
> 
> 3. Is there anybody out there who is prepared to assist me in putting
>    together a CGI-bin script for a fee? I live in Melbourne, Australia.
> 
> Your assistance is greatly appreciated!!!!!
> 
> Regards, Frank C.

does anyone knows where can i get it ??
 please e-mail me..
thanks in advance...

Kiyoshi.
al282444@academ01.slp.itesm.mx

Hello !

The Last Unicorn wrote:
> 
> does anyone knows where can i get it ??
>  please e-mail me..

 Check out

   http://www.perl.com/perl/info/software.html


 Hope this helps, Eike

=====================================================================
 Eike Grote, Theoretical Physics IV, University of Bayreuth, Germany
            email : eike.grote@theo.phy.uni-bayreuth.de
         URL : http://btrzxa.fddi.uni-bayreuth.de/~btpa25/
=====================================================================

In article <318709AF.2A95@daemon.apana.org.au> "Frank C." <chopperb@daemon.apana.org.au> writes:
   I am almost ready to launch my own home page which contains an 
   interactive Web spot requiring a Perl script. However my system 
   administrator will not accept Perl because of the alleged security 
   problems. My own research reveals that most interactive Web pages - 
   approximately 80% - use Perl scripts to execute them. Thus I require 
   advice on the following matters:

   1. What security hazard does Perl actually pose?

Perl doesn't pose any more security problems than any other language.  Ask
your administrator if he'll accept something else (a shell script, for
example).  Any language can be a security hazard if your server is set up
incorrectly.  The majority of all problems can be fixed simply by running
the server as user "nobody".  You will want to make sure that your script
runs correctly under the -w flag as well as "use strict subs/vars".  Also,
check out the section on security in the Camel book or the perlsec manpage.

   2. How do I rectify the problem i.e. where can I get a suitable CGI 
      script?

This will be up to your admin.  He may simply say "no CGI", except system
staff or something like that.  If that is the case, you're probably stuck.
Or you can use the old "vote with your feet" paradigm: go to another
provider, or if this is work try complaining to his boss.

   3. Is there anybody out there who is prepared to assist me in putting
      together a CGI-bin script for a fee? I live in Melbourne, Australia.

If you'll pay travel expenses.  ;-)

-spp
-- 
Stephen P Potter  Pencom Systems Administration  Mobil Global Financial Markets 
spp@psa.pencom.com	Pager: 1-800-759-8888, 187-0318     Work: 703-860-2222
     Maintainer of <A HREF="http://perl.com/perl/faq/">Perl FAQ List</A>
   "I'm supposed to be their God, and I've broken five of their commandments 
   already.  I'd've broken all six, but there aren't any sheep on board."
		-Dave Lister, 3rd technician, Red Dwarf

Eike Grote <eike.grote@theo.phy.uni-bayreuth.de> writes:

>   http://www.perl.com/perl/info/software.html

C'mon ... be a little more link friendly:  :)

    ftp://ftp.dstc.edu.au/pub/perl

Cheers 
-- 
Marcus Barczak, <mjb@siva.apana.org.au>

In <318709AF.2A95@daemon.apana.org.au> "Frank C."
<chopperb@daemon.apana.org.au> writes: 
>
>Dear Netizens,
>
>I am almost ready to launch my own home page which contains an 
>interactive Web spot requiring a Perl script. However my system 
>administrator will not accept Perl  [snip]

Frank:

If you're wanting to use a form page, try constructing your page using
Webmania Professional 1.5.  I use it and it saves me having to learn
perl/cgi. It sends the form data to my pop3 email.

hawk
-- 
hawks1@ix.netcom.com

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"Happiness is ..." 
 & Iowa Pioneer    <http://www.digiserve.com/ladyhawk/toc.htm
 Project
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In article <318709AF.2A95@daemon.apana.org.au>,
Frank C. <chopperb@daemon.apana.org.au> wrote:
>Dear Netizens,
>
>I am almost ready to launch my own home page which contains an 
>interactive Web spot requiring a Perl script. However my system 
>administrator will not accept Perl because of the alleged security 
>problems. My own research reveals that most interactive Web pages - 
>approximately 80% - use Perl scripts to execute them. Thus I require 
>advice on the following matters:
>
>1. What security hazard does Perl actually pose?
>
>2. How do I rectify the problem i.e. where can I get a suitable CGI 
>   script?
>
>3. Is there anybody out there who is prepared to assist me in putting
>   together a CGI-bin script for a fee? I live in Melbourne, Australia.

We have an environment here too where arbitrary user-written CGI
programs are unacceptable on our central system. That is precisely
why I wrote safecgiperl, built around the Safe extension module.
Extracting from the README:

   Thanks to an extension module for Perl which allows compartmentalised
   execution we can now ensure that user-written CGI programs written in
   Perl can be executed safely. Only a restricted set of the Perl language
   is available: uses of unsafe features (even within eval statements) are
   trapped and the program is not run.
   ...
   There are many Perl operators not available to the compartment in
   which your CGI program is run. These mostly include operators which
   provide access to the operating system. The following list is not
   exhaustive but includes the most common excluded operators:
   * system, `backticks`, exec, fork, syscall, signal handlers,
     pipes (including open(FOO, "|bar") and open(FOO, "bar|"))
   * network access (socket, bind, connect, ...)
   * File munging (rename, link, opendir, chown, ...)
   * System V IPC (shared memory, message queues, semaphores)
   * File tests (-r, -w, -l, ...)
   * Calling perl on other files (require, use, do 'file')

   Opening files for reading/writing is restricted. The "open" command
   is subject to the following restrictions:
   * Files opened for reading must be owned by the user.
   * Files opened for writing must be opened by using a filename containing
     no "/" characters. The filename is taken to live in the directory
     ~/cgi/out and the file must already exist at the time the open is
     performed. It can be a symbolic link if desired.

The current release is beta1 which was written for perl 5.001m.
A patch that comes with safegciperl-b1 fixes a couple of lines
for use with perl 5.002 (Safe now comes distributed as an official
part of perl and the error return API changed slightly from the beta).
There is a further fix that needs doing to get the open() wrapper
working with perl5.002: changing
     *{$cpt->varglob("open")} = sub {
to
     *{"$root\::open"} = sub {
in cgiperl. An irritating but harmless message to stderr can be worked
around by applying a patch to Safe.pm or waiting for the next release
(bug fixed by Tim Bunce, thanks). Because of all these minor nuisances,
I'm going to put together a proper 1.0 distribution of safecgiperl
shortly. You can get beta1 from
    ftp://ftp.ox.ac.uk/pub/perl/safecgiperl-b1.tar.gz

It's been running on our central Unix service for 7 months now and there
are a few thousand hits a day on user-written safeperl CGI programs.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee

Frank C. wrote:
> 
> Dear Netizens,
> 
> I am almost ready to launch my own home page which contains an
> interactive Web spot requiring a Perl script. However my system
> administrator will not accept Perl because of the alleged security
> problems. My own research reveals that most interactive Web pages -
> approximately 80% - use Perl scripts to execute them. Thus I require
> advice on the following matters:
> 
> 1. What security hazard does Perl actually pose?
>

It's not Perl itself that's the problem; it's the fact that CGI
developers can put rogue scripts on the system that can do 
very bad things.  ISP admins would rather not worry about that
issue.
 
> 2. How do I rectify the problem i.e. where can I get a suitable CGI
>    script?
>

Run your own server.
 
> 3. Is there anybody out there who is prepared to assist me in putting
>    together a CGI-bin script for a fee? I live in Melbourne, Australia.
>

I'm sure there is ;-)
 

--
// James V. Reagan
// http://jreagan.pr.mcs.net
// mailto:jreagan@mcs.net

In article <4mppfq$81d@news.ox.ac.uk>,
Malcolm Beattie <mbeattie@sable.ox.ac.uk> wrote:
>In article <318709AF.2A95@daemon.apana.org.au>,
>Frank C. <chopperb@daemon.apana.org.au> wrote:

>>[...] My own research reveals that most interactive Web pages - 
>>approximately 80% - use Perl scripts to execute them. Thus I require 
>>advice on the following matters:
>>
>>1. What security hazard does Perl actually pose?
>>
>>2. How do I rectify the problem i.e. where can I get a suitable CGI 
>>   script?

>   Thanks to an extension module for Perl which allows compartmentalised
>   execution we can now ensure that user-written CGI programs written in
>   Perl can be executed safely. Only a restricted set of the Perl language
>   is available: uses of unsafe features (even within eval statements) are
>   trapped and the program is not run.

That covers one dimension of security, but some scripts can deliberately 
or otherwise consume enough resources to effectively deny service on the 
server.  Aspects such as process table slots, files opened per process, 
number of concurrent processes, and amount of CPU consumed are some of 
the things that worry me.  Some scripts are used tens of times a day and 
work well, the same scripts may cripple a machine if they are run tens of 
times a second.  Some of these issues can be addressed by setting 
suitable resource limits in the script, others need a more global view of 
the machine and HTTP server state to be tackled.

Just a thought,

Mike

-- 
Mike Stok                         |            The "`Stok' disclaimers" apply.
mike@stok.co.uk                   |    PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.stok.co.uk/~mike/      |                    65 F3 3F 1D 27 22 B7 41
stok@pencom.com                   |       Pencom Systems Administration (work)