David, Richard, & Bruce -
Thanks to all - I have learned lots however still not enough to solve
the original problem -
Anyway, after I edit mod_perl.con to include the suggested changes I
still can't run scripts from /srv/www/perl-lib that work in
/srv/www/cgi-bin --
....................................................................
edited mod_perl.conf
<Directory "/srv/www/perl-lib">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
<IfModule mod_perl.c>
PerlRequire "/etc/apache2/mod_perl-startup.pl"
ScriptAlias /perl/ "/srv/www/perl-lib/"
<Location /perl/>
# mod_perl mode
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Order allow,deny
Allow from all
</Location>
ScriptAlias /cgi-perl/ "/srv/www/perl-lib/"
<Location /cgi-perl>
# perl cgi mode
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
Options +ExecCGI
</Location>
# The /cgi-bin/ ScriptAlias is already set up in httpd.conf
</IfModule>
# vim: ft=apache
..............................................................................
Hmmmmmmm.....................
All very wierd -
Thanks -
Michael
On 3/15/07, David Bolt <[EMAIL PROTECTED]> wrote:
On Thu, 15 Mar 2007, Richard Bos <[EMAIL PROTECTED]> wrote:-
>Op donderdag 15 maart 2007 21:30, schreef David Bolt:
>> >Now why oh why did they ship the mod_perl.conf file that way when they
>> >had created the directory /srv/www/perl-lib to put perl scripts in?
>>
>> No idea. I always install any scripts into /cgi-bin/. It makes things
>> much easier as it "just works".
>>
>> >The next question is - how do you fix the file to get it to work?
>>
>> If you really want to use it, it just needs a few of changes.
>
>Do perl scripts work from userdir ($HOME/public_html or
>$HOME/public_html/cgi-bin) as well.
Not here they don't[0], which is a Good Thing(tm).
>Or does that need changes to the config
>file as well?
To open up that sort of security hole would require changes to the
config file(s), changes I personally would not make.
As to the security hole. Adding a binary or script to /srv/www/cgi-bin,
/srv/www/cgi-perl or /srv/www/perl-lib requires the root password.
Adding a random binary or script to ~/public_html/cgi-bin/ only requires
user-level access. It's possible, although unlikely, that this could be
a vector for installing a root-kit.
[0] Tested because, even though I thought it wouldn't work, I just
wanted to make sure I didn't have a hole to close:
[EMAIL PROTECTED]:~> mkdir public_html/cgi-bin
[EMAIL PROTECTED]:~> sed -e 's#2.0 rocks#2.0 breaks rocks#g'
</srv/www/cgi-bin/test.pl >~/public_html/cgi-bin/test.pl
[EMAIL PROTECTED]:~> telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /~davjam/cgi-bin/test.pl HTTP/1.0
HTTP/1.1 200 OK
Date: Thu, 15 Mar 2007 21:33:54 GMT
Server: Apache/2.2.3 (Linux/SUSE)
Last-Modified: Thu, 15 Mar 2007 21:33:35 GMT
ETag: "69143-5c-42bbde01309c0"
Accept-Ranges: bytes
Content-Length: 92
Connection: close
Content-Type: application/x-perl
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "mod_perl 2.0 breaks rocks!\n";
Connection closed by foreign host.
Regards,
David Bolt
--
Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/
RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit
RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit
TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a1 32bit
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
