cgiwrap-users

[cgiwrap-users] apache problem

[alex <al...@ab...>]

Hi,

I installed cgiwrap with this configure

./configure --with-install-dir=3D/usr/local/cgiwrap =
--with-httpd-user=3Dwww-data =
--with-logging-file=3D/var/log/apache/cgiwrap.log

on a debian sarge box, my apache version is 1.3.33 =20

i put this in my httpd.conf

ScriptAlias /cgiwrapDir/ /usr/local/cgiwrap/
Action cgi-wrapper /cgiwrapDir/cgiwrap


but i can not restart apache daemon, I have this error

Syntax error on line 1060 of /etc/apache/httpd.conf:
Invalid command 'Action', perhaps mis-spelled or defined by a module not =
included in the server configuration

[cgiwrap-users] Installation Issue on Pentium Servers

[<ers...@ms...>]

Has anyone encountered and resolved the following error when 
running ./configure during the installation of CGIWrap? We are 
attempting to install CGIWrap on a Dell Blade (Pentium Xeon) running 
SuSE Linux 9.2

This is the error:

checking build system type... Invalid configuration `x86_64-pc-linux-
gnuoldld':machine 
`x86_64-pc' not recognized

[cgiwrap-users] [PATCH] support "nph-" & "php-" when full path in argv[0]

[<ms...@fr...>]

I think recent versions of Apache 2 include CGIwrap's full path in 
argv[0]

Consequently, php-cgiwrap started complaining that my phps lacked 
executable permissions

This was a problem with CGIwrap -

util.c:679 - if we're passing to interpreter, isn't an error to be 
non-executable

Instead, Context.interpreted_script wasn't getting set, because argv[0] 
no-longer started with "php-" (it was "/.../php-cgiwrap")

This patch fixes the problem for me. I tested it in the case that 
argv[0] is a full path & that it is just the last component

Many thanks for CGIwrap!

Jack

Re: [cgiwrap-users] Autoresponder on cgiwrap-users list

[Nathan N. <nn...@um...>]

They have been removed.

-- Nathan

On Wed, Jul 06, 2005 at 05:33:51AM -0700, Jeremy Chadwick wrote:
> Can the administrator of this list please address the following matter
> in any way he/she sees fit?  Autoresponders which are subscribed to
> mailing lists aren't very cool...
> 
> Thanks.
> 
> -- 
> | Jeremy Chadwick                                 jdc at parodius.com |
> | Parodius Networking                        http://www.parodius.com/ |
> | UNIX Systems Administrator                   Mountain View, CA, USA |
> | Making life hard for others since 1977.                             |
> 
> --- SNIP ---
> 
> >> From ad...@lu...  Wed Jul  6 03:31:31 2005
> >> Return-Path: <ad...@lu...>
> >> Received: from luna.mysticmoonhosting.com (luna.mysticmoonhosting.com [67.43.10.131])
> >> 	by mx1.parodius.com (Postfix) with ESMTP id 256C45E14
> >> 	for <cg...@jd...>; Wed,  6 Jul 2005 03:31:30 -0700 (PDT)
> >> Received: from advance by luna.mysticmoonhosting.com with local (Exim 4.50)
> >> 	id 1Dq7BW-0002Q8-Ot
> >> 	for cg...@jd...; Wed, 06 Jul 2005 06:31:18 -0400
> >> To: Jeremy Chadwick <cg...@jd...>
> >> X-Autorespond: Re: [cgiwrap-users] CGIWrap and Nagios issues
> >> X-Loop: Jeremy Chadwick <cg...@jd...>
> >> From: "Advance Services Team" <in...@ad...>
> >> Content-type: text/plain; charset=us-ascii
> >> Subject: Re: Re: [cgiwrap-users] CGIWrap and Nagios issues
> >> Message-Id: <E1D...@lu...>
> >> Date: Wed, 06 Jul 2005 06:31:18 -0400
> >> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
> >> X-AntiAbuse: Primary Hostname - luna.mysticmoonhosting.com
> >> X-AntiAbuse: Original Domain - jdc.parodius.com
> >> X-AntiAbuse: Originator/Caller UID/GID - [32103 32003] / [47 12]
> >> X-AntiAbuse: Sender Address Domain - luna.mysticmoonhosting.com
> >> X-Source: /usr/local/cpanel/bin/autorespond
> >> X-Source-Args: /usr/local/cpanel/bin/autorespond in...@ad... /home/advance/.autorespond 
> >> X-Source-Dir: /
> >> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on 
> >> 	pentarou.parodius.com
> >> X-Spam-Level: 
> >> X-Spam-Status: No, score=0.0 required=3.0 tests=none autolearn=ham 
> >> 	version=3.0.4
> >> Status: RO
> >> Content-Length: 68
> >> Lines: 3
> >> 
> >> Thank you for contacting us.
> >> 
> >> I will respond to your message ASAP !
> >> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216

Re: [cgiwrap-users] CGIWrap and Nagios issues

[Nathan N. <nn...@um...>]

Directory will definately not work, because apache has no idea what directory
is being used... That is all handled internally to cgiwrap.

On Wed, Jul 06, 2005 at 05:23:30AM -0700, Jeremy Chadwick wrote:
> I don't think <Directory> will work.  Use a <Location>.  :-)
> 
> -- 
> | Jeremy Chadwick                                 jdc at parodius.com |
> | Parodius Networking                        http://www.parodius.com/ |
> | UNIX Systems Administrator                   Mountain View, CA, USA |
> | Making life hard for others since 1977.                             |
> 
> On Wed, Jul 06, 2005 at 09:25:21PM +1000, James Turnbull wrote:
> > Jeremy Chadwick wrote:
> > 
> > >Using ScriptAlias and the like to map CGI executions to usernames
> > >and the like won't result in Apache honouring .htaccess.  I believe
> > >the problem to be more related to Apache than cgiwrap.
> > >
> > >For workarounds, there's only one that I've found: use a <Directory>
> > >or <Location> block and add appropriate .htaccess-esque rules there.
> > >
> > >Aren't the oversights of Apache wonderful?  ;-)
> > >
> > Sadly I am not using a .htaccess file and in fact putting the directives 
> > directly into the httpd.conf file like:
> > 
> >    <Directory "/usr/local/nagios/sbin/">
> >        AllowOverride None
> >        Options ExecCGI
> >        Order allow,deny
> >        Allow from all
> >        AuthName "Nagios Access"
> >        AuthType Digest
> >        AuthDigestFile /usr/local/nagios/etc/htdigest.users
> >        Require valid-user
> >    </Directory>
> > 
> > This does not seem to fix the problem.  Any other ideas would be much 
> > appreciated.  What little hair I have left I am slowly pulling out. :)
> > 
> > Regards
> > 
> > James Turnbull
> > 
> > -- 
> > James Turnbull <ja...@lo...>
> > ---
> > Author of Hardening Linux, Apress
> > (http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
> > ---
> > PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216

[cgiwrap-users] Autoresponder on cgiwrap-users list

[Jeremy C. <cg...@jd...>]

Can the administrator of this list please address the following matter
in any way he/she sees fit?  Autoresponders which are subscribed to
mailing lists aren't very cool...

Thanks.

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.                             |

--- SNIP ---

>> From ad...@lu...  Wed Jul  6 03:31:31 2005
>> Return-Path: <ad...@lu...>
>> Received: from luna.mysticmoonhosting.com (luna.mysticmoonhosting.com [67.43.10.131])
>> 	by mx1.parodius.com (Postfix) with ESMTP id 256C45E14
>> 	for <cg...@jd...>; Wed,  6 Jul 2005 03:31:30 -0700 (PDT)
>> Received: from advance by luna.mysticmoonhosting.com with local (Exim 4.50)
>> 	id 1Dq7BW-0002Q8-Ot
>> 	for cg...@jd...; Wed, 06 Jul 2005 06:31:18 -0400
>> To: Jeremy Chadwick <cg...@jd...>
>> X-Autorespond: Re: [cgiwrap-users] CGIWrap and Nagios issues
>> X-Loop: Jeremy Chadwick <cg...@jd...>
>> From: "Advance Services Team" <in...@ad...>
>> Content-type: text/plain; charset=us-ascii
>> Subject: Re: Re: [cgiwrap-users] CGIWrap and Nagios issues
>> Message-Id: <E1D...@lu...>
>> Date: Wed, 06 Jul 2005 06:31:18 -0400
>> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
>> X-AntiAbuse: Primary Hostname - luna.mysticmoonhosting.com
>> X-AntiAbuse: Original Domain - jdc.parodius.com
>> X-AntiAbuse: Originator/Caller UID/GID - [32103 32003] / [47 12]
>> X-AntiAbuse: Sender Address Domain - luna.mysticmoonhosting.com
>> X-Source: /usr/local/cpanel/bin/autorespond
>> X-Source-Args: /usr/local/cpanel/bin/autorespond in...@ad... /home/advance/.autorespond 
>> X-Source-Dir: /
>> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on 
>> 	pentarou.parodius.com
>> X-Spam-Level: 
>> X-Spam-Status: No, score=0.0 required=3.0 tests=none autolearn=ham 
>> 	version=3.0.4
>> Status: RO
>> Content-Length: 68
>> Lines: 3
>> 
>> Thank you for contacting us.
>> 
>> I will respond to your message ASAP !
>> 

Re: [cgiwrap-users] CGIWrap and Nagios issues

[Jeremy C. <cg...@jd...>]

I don't think <Directory> will work.  Use a <Location>.  :-)

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.                             |

On Wed, Jul 06, 2005 at 09:25:21PM +1000, James Turnbull wrote:
> Jeremy Chadwick wrote:
> 
> >Using ScriptAlias and the like to map CGI executions to usernames
> >and the like won't result in Apache honouring .htaccess.  I believe
> >the problem to be more related to Apache than cgiwrap.
> >
> >For workarounds, there's only one that I've found: use a <Directory>
> >or <Location> block and add appropriate .htaccess-esque rules there.
> >
> >Aren't the oversights of Apache wonderful?  ;-)
> >
> Sadly I am not using a .htaccess file and in fact putting the directives 
> directly into the httpd.conf file like:
> 
>    <Directory "/usr/local/nagios/sbin/">
>        AllowOverride None
>        Options ExecCGI
>        Order allow,deny
>        Allow from all
>        AuthName "Nagios Access"
>        AuthType Digest
>        AuthDigestFile /usr/local/nagios/etc/htdigest.users
>        Require valid-user
>    </Directory>
> 
> This does not seem to fix the problem.  Any other ideas would be much 
> appreciated.  What little hair I have left I am slowly pulling out. :)
> 
> Regards
> 
> James Turnbull
> 
> -- 
> James Turnbull <ja...@lo...>
> ---
> Author of Hardening Linux, Apress
> (http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
> ---
> PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)
> 
> 
> 
> 

Re: [cgiwrap-users] CGIWrap and Nagios issues

[James T. <ja...@lo...>]

Jeremy Chadwick wrote:

>Using ScriptAlias and the like to map CGI executions to usernames
>and the like won't result in Apache honouring .htaccess.  I believe
>the problem to be more related to Apache than cgiwrap.
>
>For workarounds, there's only one that I've found: use a <Directory>
>or <Location> block and add appropriate .htaccess-esque rules there.
>
>Aren't the oversights of Apache wonderful?  ;-)
>
Sadly I am not using a .htaccess file and in fact putting the directives 
directly into the httpd.conf file like:

    <Directory "/usr/local/nagios/sbin/">
        AllowOverride None
        Options ExecCGI
        Order allow,deny
        Allow from all
        AuthName "Nagios Access"
        AuthType Digest
        AuthDigestFile /usr/local/nagios/etc/htdigest.users
        Require valid-user
    </Directory>

This does not seem to fix the problem.  Any other ideas would be much 
appreciated.  What little hair I have left I am slowly pulling out. :)

Regards

James Turnbull

-- 
James Turnbull <ja...@lo...>
---
Author of Hardening Linux, Apress
(http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

Re: [cgiwrap-users] CGIWrap and Nagios issues

[Jeremy C. <cg...@jd...>]

Using ScriptAlias and the like to map CGI executions to usernames
and the like won't result in Apache honouring .htaccess.  I believe
the problem to be more related to Apache than cgiwrap.

For workarounds, there's only one that I've found: use a <Directory>
or <Location> block and add appropriate .htaccess-esque rules there.
Aren't the oversights of Apache wonderful?  ;-)

Example configuration: one of our virtualhosts uses cgiwrap to assist
in managing their web board software (ugh...).  The board requires
authentication to post (but not read).  Since cgiwrap is involved,
there is no way to achieve the authentication without actually
modifying the CGI to do the authentication itself (rather than rely
on Apache's .htaccess allow/deny and authentication directives).
To alleviate this problem, I had to do the following within our
Apache config, within their <VirtualHost> block:

  ScriptAlias /cgi-bin/   "/usr/local/www/cgi-bin/cgiwrap/user/"

  <Location /cgi-bin/bbs/secure>
    AuthType Basic
    AuthName "Restricted Access"
    AuthUserFile "/home/user/cgi-bin/bbs/secure/.htpasswd"
    Require valid-user
  </Location>

{rant}
Aren't the oversights of Apache wonderful?  For a webserver that
something like 80-90% of the Internet relies on, I'd expect it to
have better logic/directives for handling such situations.  Hell,
better yet, solve the problem altogether: add setuid() support for
CGIs and documents to Apache natively, WITHOUT suexec (which is just
an ugly hack).  And while they're at it, add rate-limiting support,
and proper bandwidth monitoring to the stock Apache server, rather
than relying on half-ass third-party modules which don't work or
require you to patch the Apache core to get SHM to work...
{/rant}

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.                             |

On Wed, Jul 06, 2005 at 08:13:18PM +1000, James Turnbull wrote:
> James Turnbull wrote:
> 
> >Hi
> >
> >I've configured Nagios and Apache to work with CGIWrap.  I sym-linked 
> >a /home/nagios/public_html/ directory to the Nagios CGI directory 
> >/usr/local/nagios/sbin.  Everything seems to work and cgiwrap seems to 
> >be working but I also use authentication (Digest authentication) to 
> >authenticate my users.  In Nagios authenticated users are then used to 
> >determine what access is granted to the Nagios web console.  But after 
> >installing CGIWrap Nagios seems unable to work out what user is signed 
> >in and hence doesn't correctly authorize users.  In Nagios this shows 
> >up as the signed in user name being replaced with a ?, ie. instead of 
> >the console saying jsmith is signed in it says that ? is signed in.
> >
> To add further information - I have noted from the documentation that 
> CGIWrap doesn't work with .htaccess files - does this imply it doesn't 
> work with Apache authentication directives that are contained in either 
> .htaccess files or the httpd.conf file?
> 
> Regards
> 
> James Turnbull
> 
> -- 
> James Turnbull <ja...@lo...>
> ---
> Author of Hardening Linux, Apress
> (http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
> ---
> PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)
> 
> 
> 
> 

Re: [cgiwrap-users] CGIWrap and Nagios issues

[James T. <ja...@lo...>]

James Turnbull wrote:

> Hi
>
> I've configured Nagios and Apache to work with CGIWrap.  I sym-linked 
> a /home/nagios/public_html/ directory to the Nagios CGI directory 
> /usr/local/nagios/sbin.  Everything seems to work and cgiwrap seems to 
> be working but I also use authentication (Digest authentication) to 
> authenticate my users.  In Nagios authenticated users are then used to 
> determine what access is granted to the Nagios web console.  But after 
> installing CGIWrap Nagios seems unable to work out what user is signed 
> in and hence doesn't correctly authorize users.  In Nagios this shows 
> up as the signed in user name being replaced with a ?, ie. instead of 
> the console saying jsmith is signed in it says that ? is signed in.
>
To add further information - I have noted from the documentation that 
CGIWrap doesn't work with .htaccess files - does this imply it doesn't 
work with Apache authentication directives that are contained in either 
.htaccess files or the httpd.conf file?

Regards

James Turnbull

-- 
James Turnbull <ja...@lo...>
---
Author of Hardening Linux, Apress
(http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

[cgiwrap-users] CGIWrap and Nagios issues

[James T. <ja...@lo...>]

Hi

I've configured Nagios and Apache to work with CGIWrap.  I sym-linked a 
/home/nagios/public_html/ directory to the Nagios CGI directory 
/usr/local/nagios/sbin.  Everything seems to work and cgiwrap seems to 
be working but I also use authentication (Digest authentication) to 
authenticate my users.  In Nagios authenticated users are then used to 
determine what access is granted to the Nagios web console.  But after 
installing CGIWrap Nagios seems unable to work out what user is signed 
in and hence doesn't correctly authorize users.  In Nagios this shows up 
as the signed in user name being replaced with a ?, ie. instead of the 
console saying jsmith is signed in it says that ? is signed in.

I am running Red Hat ES 4 with Apache 2.0.52, Nagios 2.0b3 and cgiwrap 
3.9.  Happy to provide any further information if this is not detailed 
enough.

Thanks in advance

James Turnbull

-- 
James Turnbull <ja...@lo...>
---
Author of Hardening Linux, Apress
(http://www.amazon.com/exec/obidos/tg/detail/-/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

Re: [cgiwrap-users] CGI and .htaccess precedence

[Nathan N. <nn...@um...>]

Please read docs - cgiwrap will not work with .htaccess files as you have 
described. There is a specific mechanism that has to be followed. If 
that type of support is critical, have a look at suexec.

-- Nathan

On Tue, Jun 21, 2005 at 11:36:40AM +0100, gwilson wrote:
> Hi all!
> 
> I am using CGI wrap along with rewrite rules to basically force all .php 
> files to be
> executed through cgiwrap - this works very well.
> 
> I havce noticed off behaviour though.  If I create a .htaccess and 
> .htpasswd in a
> directory and have an index.html file in there too - when I browse to 
> it, I get prompted
> for the username and password as you would expect.
> 
> But if I replace the index.html with an index.php - somehow CGI wrap takes
> precedence and the contents of the file is displayed instead of being
> asked for a username and password.
> 
> Can anyone explain why this happens and what needs to be done to get Apache
> to utilise .htaccess BEFORE anything else?
> 
> Many thanks
> 
> GW
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 
-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216

[cgiwrap-users] CGI and .htaccess precedence

[gwilson <gw...@pl...>]

Hi all!

I am using CGI wrap along with rewrite rules to basically force all .php 
files to be
executed through cgiwrap - this works very well.

I havce noticed off behaviour though.  If I create a .htaccess and 
.htpasswd in a
directory and have an index.html file in there too - when I browse to 
it, I get prompted
for the username and password as you would expect.

But if I replace the index.html with an index.php - somehow CGI wrap takes
precedence and the contents of the file is displayed instead of being
asked for a username and password.

Can anyone explain why this happens and what needs to be done to get Apache
to utilise .htaccess BEFORE anything else?

Many thanks

GW

Re: [cgiwrap-users] SCRIPT_NAME env variable

[Gary W. <gw...@pl...>]

On Fri, 2005-05-20 at 17:33 +0100, Gary Wilson wrote:
> Hi!
> 
> I am having some issues in beta testing with my new CGI solution - it is
> using Apache and mod rewrite to make all PHP files get parsed as a CGI
> binary, through CGI_WRAP.  Test users however are complaining that
> several environment variables are getting mangled through the solution,
> which is preventing certain script packages install scripts from working
> correctly.  The first report was SCRIPT_NAME being prepended with the
> username e.g. /testuser1/phpinfo.php when it _should_ read just
> phpinfo.php
> 
> After a bit of testing, it seems it is CGI_WRAP adding this info in
> (presumably to allow things to work in a flat virtualhost environment 
> or similar?)  But it seems to be tripping my users up on my solution.
> 
> Can someone confirm that the code in util.c which starts with the
> comment "Set the correct SCRIPT_NAME environment variable" is in fact
> doing the mangling I refer to, and if so, is this behaviour
> configurable, or shall I just tweak the c code to do what I need?
> 

Ah ha - I found the --with-use-script-url compile option which fixed
everything that's actually broken. 

However, I am having an aesthetic issue (cannot believe how petty this
user is_ with the _SERVER["SCRIPT_FILENAME"] and _ENV["SCRIPT_FILENAME"]
variables, which BOTH have 2 extra slashes between the directory path
and the filename:

They show (e.g.): /files/home1/inttestpn1///phpinfo.php
They should show: /files/home1/inttestpn1/phpinfo.php

But I am failling to see where they are being introduced.  On a similar
vein, the PATH_TRANSLATED variable has the username in
twice: /files/home1/inttestpn1/inttestpn1/phpinfo.php for no obvious
reason.  None of these errors are giving me any functionality headaches,
purely aesthetic (i.e. the users see the contents are wrong and
complain, ignoring the fact the the contents aren't used or have slashes
in that don't make a difference)

Can anyone advise where these extra slashes and an extra username might
be coming from?

Thanks

Gary

[cgiwrap-users] SCRIPT_NAME env variable

[Gary W. <gw...@pl...>]

Hi!

I am having some issues in beta testing with my new CGI solution - it is
using Apache and mod rewrite to make all PHP files get parsed as a CGI
binary, through CGI_WRAP.  Test users however are complaining that
several environment variables are getting mangled through the solution,
which is preventing certain script packages install scripts from working
correctly.  The first report was SCRIPT_NAME being prepended with the
username e.g. /testuser1/phpinfo.php when it _should_ read just
phpinfo.php

After a bit of testing, it seems it is CGI_WRAP adding this info in
(presumably to allow things to work in a flat virtualhost environment 
or similar?)  But it seems to be tripping my users up on my solution.

Can someone confirm that the code in util.c which starts with the
comment "Set the correct SCRIPT_NAME environment variable" is in fact
doing the mangling I refer to, and if so, is this behaviour
configurable, or shall I just tweak the c code to do what I need?

Thanks

Gary

[cgiwrap-users] problem with sctips in subidrectories

[Alexandr L. <a.l...@gm...>]

Hi, I'm trying to get cgiwrapper to work with=20

Mandrake Linux release 10.0 (Official) for i586

PHP 5.0.4 (cli) (built: May 10 2005 14:13:25)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies

apache 2.0.54

The problem I'm having is, the scripts places in ~username/public_html
directory will be executed absolutely fine. But if there is some
subfolder, say  ~username/public_html/subfolder
and a script inside, it will complain about not being able to open the
script files
cgiwprad   log follows


Initializing Logging
Redirecting STDERR to STDOUT

Setting SIGXCPU to default behaviour

Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/cgi-bin/cgiwrapd'
  SCRIPT_FILENAME: '/usr/local/apache2/cgi-bin/cgiwrapd'
     REDIRECT_URL: '<NULL>'
        PATH_INFO: '/~j_schuma/test/test.php'
  PATH_TRANSLATED: '/home/j_schuma/public_html/test/test.php'
      REMOTE_USER: '<NULL>'
      REMOTE_HOST: '<NULL>'
      REMOTE_ADDR: '127.0.0.1'


Trying to extract user from PATH_INFO.
Retrieved User Name:  'username'

User Data Retrieved:
     UserID: 'username'
        UID: '4234'
        GID: '4234'
   Home Dir: '/home/username'
Checking user minimum uid.

Script Base Directory:  '/home/username/public_html/.'
=09Fetching script string

Trying to extract script from PATH_INFO
Extracted PATH_INFO '/test/test.php'
=09Building script path

=09Condensing slashes.

=09Script Relative Path:  'test/test.php'
=09Script Absolute Path:  '/home/username/public_html/./test/test.php'
=09Checking for special interpreted script (php).
=09Interpreter Path:  '/usr/local/bin/php'

Fixing Environment Variables.

Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/cgi-bin/cgiwrapd/username/test/test.php'
  SCRIPT_FILENAME: '/home/username/public_html/./test/test.php'
     REDIRECT_URL: '<NULL>'
        PATH_INFO: '<NULL>'
  PATH_TRANSLATED: '/home/j_schuma/public_html/test/test.php'
      REMOTE_USER: '<NULL>'
      REMOTE_HOST: '<NULL>'
      REMOTE_ADDR: '127.0.0.1'


UIDs/GIDs Changed To:
   RUID: '4234'
   EUID: '4234'
   RGID: '4234'
   EGID: '4234'

Changing current directory to '/home/username/public_html/./test'



Output of script follows:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
Could not open input file: /test.php.



If i change the permissions on the script so it does not pass the
security check in cgi wrapper.  The cgi wrapper will actually complain
about it,  so it 'sees' the file...
Any ideas, pointers?

--=20
wbr, Alex

[cgiwrap-users] PHP in cgiwrap don't work after upgrade of PHP/Apache err500

[<an...@tx...>]

Hi.
I'm brand new to this mailing list, tough not new to cgiwrap. I write
because I recently did an upgrade to Apache and PHP, and then PHP-scripts
don't work in cgiwrap anymore. I upgraded to v.1.3.33 of Apache, and
v.4.3.11 of PHP. The old versions where around 1 year old.

It seem like if I run cgiwrap in debug mode the scripts work - a "hello
world" script gives correct output, but when running normal mode the server
gives me an internal server error 500. Perl scripts work fine.

I saw the FAQ telling that I should compile PHP with --enable-discard-path
witch I did not use before, but the result is the same. I've tried to
recompile/upgrade cgiwrap, also with same result. I've compared the old
compile options of PHP and Apache, but can't seem to find anything I would
expect giving me any problem.

Anyone here had a similar problem and can help me?


Andreas

Re: [cgiwrap-users] cgiwrap and PHP

[Piotr K. <ma...@ma...>]

On Thu, Mar 17, 2005 at 05:03:00PM +0000, Gary Wilson wrote:
> 
> But surely that just disables the security checks which I wanted to keep
> in?

If you look into the source of the PHP, you will see that the only
"security check" you disable with compiling without --force-cgi-redirect
is checking for redirect environment variable existence, i.e.
REDIRECT_STATUS (Apache) or HTTP_REDIRECT_STATUS (Netscape, redirect.so)
or cgi.redirect_status_env from php.ini.

This is an alert that php is run directly as simple cgi. In ancient
times people thought that php could be placed in /cgi-bin/, and it revealed
that it is not safe, because anyone from the web can call /cgi-bin/php/any_file
(php used PATH_INFO for looking for the script, similar to cgiwrap).
That is why there is a check for redirect variable.
With cgiwrap php-cgi should not be placed in /cgi-bin/ and should not
be available for anyone from the web.

> Is that the only way?

No. You can change sources of cgiwrap to set
SafePutenv("REDIRECT_STATUS=1","setting REDIRECT_STATUS");
and check if your PHP would accept this. Maybe you would need
to set cgi.fix_pathinfo=1 in php.ini

Another way is to set cgi.force_redirect=0 in php.ini,
but this might not work with all php versions.

Best regards,

-- 
Piotr Klaban

RE: [cgiwrap-users] cgiwrap and PHP

[Neulinger, N. <nn...@um...>]

Most of those facilities are designed for sites not using something like
cgiwrap or suexec. But maybe others here will have more to say.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: Gary Wilson [mailto:gw...@pl...]=20
> Sent: Thursday, March 17, 2005 11:03 AM
> To: Neulinger, Nathan
> Cc: cgi...@li...
> Subject: RE: [cgiwrap-users] cgiwrap and PHP
>=20
>=20
> But surely that just disables the security checks which I=20
> wanted to keep
> in?
>=20
> Is that the only way?
>=20
>=20
>=20
> On Thu, 2005-03-17 at 09:52 -0600, Neulinger, Nathan wrote:
> > Rebuild the PHP interpreter without force-cgi-redirect.
> >=20
> > -- Nathan
> >=20
> > ------------------------------------------------------------
> > Nathan Neulinger                       EMail:  nn...@um...
> > University of Missouri - Rolla         Phone: (573) 341-6679
> > UMR Information Technology             Fax: (573) 341-4216
> > =20
> >=20
> > > -----Original Message-----
> > > From: cgi...@li...=20
> > > [mailto:cgi...@li...] On Behalf=20
> > > Of Gary Wilson
> > > Sent: Thursday, March 17, 2005 9:21 AM
> > > To: cgi...@li...
> > > Subject: [cgiwrap-users] cgiwrap and PHP
> > >=20
> > > Hi all!
> > >=20
> > > I am facing a problem which on the face of it could have=20
> more than one
> > > solution, I wish to use PHP in CGI mode (not CLI mode)=20
> because PHP in
> > > CGI mode offers a few features/checks to make it a little=20
> more secure
> > > than offering access to the CLI version.  However, when=20
> using it in
> > > conjunction with cgiwrap, the following appears:
> > >=20
> > > __quote__
> > > Security Alert! The PHP CGI cannot be accessed directly.=20
> > >=20
> > > This PHP CGI binary was compiled with force-cgi-redirect=20
> enabled. This
> > > means that a page will only be served up if the=20
> REDIRECT_STATUS CGI
> > > variable is set, e.g. via an Apache Action directive.
> > >=20
> > > For more information as to why this behaviour exists, see=20
> the manual
> > > page for CGI security.
> > >=20
> > > For more information about changing this behaviour or=20
> re-enabling this
> > > webserver, consult the installation file that came with this
> > > distribution, or visit the manual page.
> > > __end quote___
> > >=20
> > > I can solve this by going to the CLI version, or by trying to
> > > incorporate an Action directive in my virtualhost before my=20
> > > rewrite rules (investigating this idea next), but I was=20
> wondering what
> > > are others' experiences of PHP and cgiwrap?  What is  the "best"
> > > solution to this (meaning most secure)?
> > >=20
> > > Many thanks
> > >=20
> > > GW
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from=20
> > > real users.
> > > Discover which products truly live up to the hype. Start=20
> reading now.
> > > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > > _______________________________________________
> > > cgiwrap-users mailing list
> > > cgi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> > >=20
> > >=20
> >=20
>=20
>=20
>=20

RE: [cgiwrap-users] cgiwrap and PHP

[Gary W. <gw...@pl...>]

But surely that just disables the security checks which I wanted to keep
in?

Is that the only way?



On Thu, 2005-03-17 at 09:52 -0600, Neulinger, Nathan wrote:
> Rebuild the PHP interpreter without force-cgi-redirect.
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-6679
> UMR Information Technology             Fax: (573) 341-4216
>  
> 
> > -----Original Message-----
> > From: cgi...@li... 
> > [mailto:cgi...@li...] On Behalf 
> > Of Gary Wilson
> > Sent: Thursday, March 17, 2005 9:21 AM
> > To: cgi...@li...
> > Subject: [cgiwrap-users] cgiwrap and PHP
> > 
> > Hi all!
> > 
> > I am facing a problem which on the face of it could have more than one
> > solution, I wish to use PHP in CGI mode (not CLI mode) because PHP in
> > CGI mode offers a few features/checks to make it a little more secure
> > than offering access to the CLI version.  However, when using it in
> > conjunction with cgiwrap, the following appears:
> > 
> > __quote__
> > Security Alert! The PHP CGI cannot be accessed directly. 
> > 
> > This PHP CGI binary was compiled with force-cgi-redirect enabled. This
> > means that a page will only be served up if the REDIRECT_STATUS CGI
> > variable is set, e.g. via an Apache Action directive.
> > 
> > For more information as to why this behaviour exists, see the manual
> > page for CGI security.
> > 
> > For more information about changing this behaviour or re-enabling this
> > webserver, consult the installation file that came with this
> > distribution, or visit the manual page.
> > __end quote___
> > 
> > I can solve this by going to the CLI version, or by trying to
> > incorporate an Action directive in my virtualhost before my 
> > rewrite rules (investigating this idea next), but I was wondering what
> > are others' experiences of PHP and cgiwrap?  What is  the "best"
> > solution to this (meaning most secure)?
> > 
> > Many thanks
> > 
> > GW
> > 
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from 
> > real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > cgiwrap-users mailing list
> > cgi...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> > 
> > 
> 

RE: [cgiwrap-users] cgiwrap and PHP

[Neulinger, N. <nn...@um...>]

Rebuild the PHP interpreter without force-cgi-redirect.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: cgi...@li...=20
> [mailto:cgi...@li...] On Behalf=20
> Of Gary Wilson
> Sent: Thursday, March 17, 2005 9:21 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] cgiwrap and PHP
>=20
> Hi all!
>=20
> I am facing a problem which on the face of it could have more than one
> solution, I wish to use PHP in CGI mode (not CLI mode) because PHP in
> CGI mode offers a few features/checks to make it a little more secure
> than offering access to the CLI version.  However, when using it in
> conjunction with cgiwrap, the following appears:
>=20
> __quote__
> Security Alert! The PHP CGI cannot be accessed directly.=20
>=20
> This PHP CGI binary was compiled with force-cgi-redirect enabled. This
> means that a page will only be served up if the REDIRECT_STATUS CGI
> variable is set, e.g. via an Apache Action directive.
>=20
> For more information as to why this behaviour exists, see the manual
> page for CGI security.
>=20
> For more information about changing this behaviour or re-enabling this
> webserver, consult the installation file that came with this
> distribution, or visit the manual page.
> __end quote___
>=20
> I can solve this by going to the CLI version, or by trying to
> incorporate an Action directive in my virtualhost before my=20
> rewrite rules (investigating this idea next), but I was wondering what
> are others' experiences of PHP and cgiwrap?  What is  the "best"
> solution to this (meaning most secure)?
>=20
> Many thanks
>=20
> GW
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20
>=20

[cgiwrap-users] cgiwrap and PHP

[Gary W. <gw...@pl...>]

Hi all!

I am facing a problem which on the face of it could have more than one
solution, I wish to use PHP in CGI mode (not CLI mode) because PHP in
CGI mode offers a few features/checks to make it a little more secure
than offering access to the CLI version.  However, when using it in
conjunction with cgiwrap, the following appears:

__quote__
Security Alert! The PHP CGI cannot be accessed directly. 

This PHP CGI binary was compiled with force-cgi-redirect enabled. This
means that a page will only be served up if the REDIRECT_STATUS CGI
variable is set, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the manual
page for CGI security.

For more information about changing this behaviour or re-enabling this
webserver, consult the installation file that came with this
distribution, or visit the manual page.
__end quote___

I can solve this by going to the CLI version, or by trying to
incorporate an Action directive in my virtualhost before my 
rewrite rules (investigating this idea next), but I was wondering what
are others' experiences of PHP and cgiwrap?  What is  the "best"
solution to this (meaning most secure)?

Many thanks

GW

Re: [cgiwrap-users] cgi-wrap beginners woes

[Nathan N. <nn...@um...>]

It's likely an issue with your addhandler usage. I would suggest getting
it to work being executed directly first. I personally use mod_rewrite
when doing short url's with cgiwrap, but I know some users have gone the
addhandler route sucessfully.

-- Nathan

On Tue, 2005-03-15 at 13:02 +0000, Gary Wilson wrote:
> Hi all,
> 
> Downloaded and installed cgi-wrap for the first time yesterday, using
> some sensible compile options, but something odd is happening when I 
> try to use it:
> 
> "CGIWrap was unable to find the user 'cgi-bin' in the password file on
> this server."
> 
> Which is confusing me, as cgi-wrap was compiled to be executed by user
> "nobody", as per the apache process, and it doesn't matter who owns 
> the script I try - the same error happens whether I run the script 
> owned by nobody, test1, test2 etc - none of the files are owned by 
> "cgi-bin", and indeed, as this error explains, there is not a user 
> cgi-bin on the system, so I don't see where cgi-wrap is getting this 
> info from.
> 
> Here is the full message displayed when trying to run a script (some 
> IP and hostname stuff obscured):
> 
> *start quote*
> CGIWrap Error: User not found
> 
> ________________________________________________________________________
> 
> CGIWrap was unable to find the user 'cgi-bin' in the password file on
> this server.
> 
> Check the URL and try again.
> 
> 
> ________________________________________________________________________
> 
> Local Information and Documentation: 
> 
>         CGIWrap Docs: /usr/doc/cgi 
>         
> Server Data: 
> 
>         Server Administrator/Contact: yo...@ex...
>         Server Name: removed
>         Server Port: 80
>         Server Protocol: HTTP/1.1
>         Virtual Host: removed
> 
> Request Data: 
> 
>         User Agent/Browser: Mozilla/5.0 (X11; U; Linux i686; en-US;
>         rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0
>         +dfsg.1-2)
>         Request Method: GET
>         Remote Address: removed
>         Remote Port: 51404
>         Extra Path Info: /cgi-bin/hwgt1.sh
> 
> ** End quote **
> 
> 
> Here is my configure line:
> 
> ./configure --with-perl=/usr/bin/perl --with-local-doc-url=/usr/doc/cgi
> --with-install-dir=/local/apache/cgi-bin/ --with-httpd-user=nobody
> --with-minimum-uid=100 --with-minimum-gid=100
> --with-logging-file=/local/apache/logs/cgiwrap.log
> --with-setenv-path=/bin:/usr/bin:/usr/local/bin -with-rlimit-cpu=120
> --with-rlimit-fsize=536870912
> --with-allow-file=/local/apache/conf/cgiwrap.allow
> --with-deny-file=/local/apache/conf/cgiwrap.deny
> 
> Here are my added httpd.conf lines:
> 
> AddHandler cgi-wrapper .php
> AddHandler cgi-wrapper .cgi
> AddHandler cgi-wrapper .sh
> Action cgi-wrapper /cgi-bin/cgiwrap
> 
> <Directory "/usr/apache/cgi-bin">
>         AllowOverride None
>         Options None
>         Order allow,deny
>         AddHandler cgi-script .cgi
>         Allow from all
> </Directory>
> 
> <Location /cgi-bin>
>       Options ExecCGI
>       AllowOverride FileInfo
> </Location>
> 
> 
> <Location /cgi-bin/*>
>     Options ExecCGI
>     AllowOverride FileInfo
> </Location>
> 
> 
> Notes: 
> - Neither the .allow or .deny files exist at the moment
> - The log file cgiwrap.log got created but has no content
> - User nobody's UID and GID is 65534
> - The CGI script ran fine under the standard Apache user before CGI wrap
> was installed
> - I am using Apache 2.0.53 under Linux kernel 2.6.11 with GRSec
> installed
> 
> 
> Many thanks for your help with this.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216

[cgiwrap-users] cgi-wrap beginners woes

[Gary W. <gw...@pl...>]

Hi all,

Downloaded and installed cgi-wrap for the first time yesterday, using
some sensible compile options, but something odd is happening when I 
try to use it:

"CGIWrap was unable to find the user 'cgi-bin' in the password file on
this server."

Which is confusing me, as cgi-wrap was compiled to be executed by user
"nobody", as per the apache process, and it doesn't matter who owns 
the script I try - the same error happens whether I run the script 
owned by nobody, test1, test2 etc - none of the files are owned by 
"cgi-bin", and indeed, as this error explains, there is not a user 
cgi-bin on the system, so I don't see where cgi-wrap is getting this 
info from.

Here is the full message displayed when trying to run a script (some 
IP and hostname stuff obscured):

*start quote*
CGIWrap Error: User not found

________________________________________________________________________

CGIWrap was unable to find the user 'cgi-bin' in the password file on
this server.

Check the URL and try again.


________________________________________________________________________

Local Information and Documentation: 

        CGIWrap Docs: /usr/doc/cgi 
        
Server Data: 

        Server Administrator/Contact: yo...@ex...
        Server Name: removed
        Server Port: 80
        Server Protocol: HTTP/1.1
        Virtual Host: removed

Request Data: 

        User Agent/Browser: Mozilla/5.0 (X11; U; Linux i686; en-US;
        rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0
        +dfsg.1-2)
        Request Method: GET
        Remote Address: removed
        Remote Port: 51404
        Extra Path Info: /cgi-bin/hwgt1.sh

** End quote **


Here is my configure line:

./configure --with-perl=/usr/bin/perl --with-local-doc-url=/usr/doc/cgi
--with-install-dir=/local/apache/cgi-bin/ --with-httpd-user=nobody
--with-minimum-uid=100 --with-minimum-gid=100
--with-logging-file=/local/apache/logs/cgiwrap.log
--with-setenv-path=/bin:/usr/bin:/usr/local/bin -with-rlimit-cpu=120
--with-rlimit-fsize=536870912
--with-allow-file=/local/apache/conf/cgiwrap.allow
--with-deny-file=/local/apache/conf/cgiwrap.deny

Here are my added httpd.conf lines:

AddHandler cgi-wrapper .php
AddHandler cgi-wrapper .cgi
AddHandler cgi-wrapper .sh
Action cgi-wrapper /cgi-bin/cgiwrap

<Directory "/usr/apache/cgi-bin">
        AllowOverride None
        Options None
        Order allow,deny
        AddHandler cgi-script .cgi
        Allow from all
</Directory>

<Location /cgi-bin>
      Options ExecCGI
      AllowOverride FileInfo
</Location>


<Location /cgi-bin/*>
    Options ExecCGI
    AllowOverride FileInfo
</Location>


Notes: 
- Neither the .allow or .deny files exist at the moment
- The log file cgiwrap.log got created but has no content
- User nobody's UID and GID is 65534
- The CGI script ran fine under the standard Apache user before CGI wrap
was installed
- I am using Apache 2.0.53 under Linux kernel 2.6.11 with GRSec
installed


Many thanks for your help with this.

Re: [cgiwrap-users] 403 error when using cgiwrapd

[Nathan N. <nn...@um...>]

On Tue, Jan 25, 2005 at 08:21:52PM -0500, Joe Hourcle wrote:
> 
> On Tuesday, January 25, 2005, at 01:06  PM, Green, James wrote:
> 
> >Hi all,
> >
> >I'm new to this list, so please forgive me if this question has  
> >recently been asked.  I have cgiwrap installed and it works fine;  
> >however, I have one particular script that is not functioning  
> >correctly and when I try to run it using cgiwrapd I get a "403  
> >Forbidden" error as follows:
> >================================================
> >You don't have permission to access  
> >/cgi-bin/cgiwrapd/survey/srvy/SurveyStart.pl on this server.
> >
> >Additionally, a 403 Forbidden error was encountered while trying to  
> >use an ErrorDocument to handle the request.
> >
> >
> >----------------------------------------------------------------------- 
> >---------
> >
> >Apache/2.0.40 Server at _default_ Port 80
> >===============================================
> >
> >The permissions are set correctly for the cgiwrapd link, and it is  
> >readable, writable, and executable by world, so I'm at a loss as to  
> >why I'm getting this error.  Anyone familiar with it?
> 
> 
> This is two different error messages --
> 
> 1.	You don't have permission to access ...
> 
> 	I _think_ this is the webserver complaining about cgiwrapd,
> 	which should be a symlink to cgiwrap, which needs execute,
> 	but you should make sure your script has the correct
> 	permissions as well.  [you might want to check via cgiwrap,
> 	non-debug mode, and see if you get a similar error message]
> 
> 	Symlinks are particularly deceptive, as their permissions
> 	are almost completely irrelevant -- it's the permissions of
> 	the file being linked to that matters.

Also, check if your server has Symlinks enabled in the options.

Alternatively, just make it a hard link instead of a symlink, then it
should bypass that.

> 
> 2.	403 Forbidden ...
> 
> 	This is apache's way of telling you that someone tried setting
> 	the ErrorDocument (where a specific file is read in place of
> 	an error message) but that when it tried reading the file
> 	that was referenced, it had an error (of type 403).
> 
> 	So, you'll need to read your httpd.conf, and make sure to
> 	set whatever files might be mentioned so they're readable by
> 	the webserver.
> 
> -----
> Joe Hourcle
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216