cgiwrap-users

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

[Joe H. <on...@dc...>]

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.

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

[cgiwrap-users] 403 error when using cgiwrapd

[Green, J. <jg...@ca...>]

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:
=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
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
=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

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?

Thanks,

Jim G

RE: [cgiwrap-users] Restricting SSI exec/virtual to certain directories

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

I'm not aware of it, but would sure be interested if you find one.

-- 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 Jackie Hunt
> Sent: Tuesday, January 11, 2005 10:50 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] Restricting SSI exec/virtual to=20
> certain directories
>=20
> Hello,
>=20
> I'm working on upgrading our apache server from 1.3x to 2.x.  One
> of the issues I've run into is related to allowing our campus
> community to access cgi programs in the /cgi-bin directory. =20
>=20
> When apache 1.3.x was installed, there was a patch applied to the
> apache server, which checked for all SSI exec's and made sure
> the path of the executable began with /cgi.  This allowed us to
> give our campus community the ability to use SSI's in their individual
> home pages, but restricted which cgi's they could run.  Is there a
> similar patch for apache 2.x.  The cgi-wrapper web site referred me
> to this list for information.
>=20
> Thanks for any info! Please send a copy of your response=20
> directly to me
> as well as the list.
>=20
> Jackie Hunt                                                      =20
> ACNS                                    Voice:  (970) 663-3789    =20
> Colorado State University               FAX:    (970) 491-1958
> Fort Collins, CO  80523                 Email: =20
> ja...@yu...
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20
>=20

[cgiwrap-users] Restricting SSI exec/virtual to certain directories

[Jackie H. <ja...@yu...>]

Hello,

I'm working on upgrading our apache server from 1.3x to 2.x.  One
of the issues I've run into is related to allowing our campus
community to access cgi programs in the /cgi-bin directory.  

When apache 1.3.x was installed, there was a patch applied to the
apache server, which checked for all SSI exec's and made sure
the path of the executable began with /cgi.  This allowed us to
give our campus community the ability to use SSI's in their individual
home pages, but restricted which cgi's they could run.  Is there a
similar patch for apache 2.x.  The cgi-wrapper web site referred me
to this list for information.

Thanks for any info! Please send a copy of your response directly to me
as well as the list.

Jackie Hunt                                                       
ACNS                                    Voice:  (970) 663-3789     
Colorado State University               FAX:    (970) 491-1958
Fort Collins, CO  80523                 Email:  ja...@yu...

Re: [cgiwrap-users] Why is my router getting bombarded with requests to port 36457?

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

On Mon, Jan 03, 2005 at 03:50:53PM -0800, Chris Richmond wrote:
> Hi Folks,
> 
>     I'm not positive about this, but I'm getting a zillion hits on my 
> linux router from random places
> to port 36457.  When I look that up in Google, CGIWrap comes up in the text 
> of the articles.
> Can anyone explain this?
> 
> Thx, Chris
> 
> The log entries look like this:
> 
> Jan  3 15:49:05 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
> 201.128.119.69:2443 67.164.x.x:36457 L=48 S=0x00 I=20105 F=0x4000 T=114 SYN 
> (#93)
> Jan  3 15:49:05 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
> 84.84.10.197:45264 67.164.x.x:36457 L=48 S=0x00 I=47078 F=0x4000 T=111 SYN 
> (#93)
> Jan  3 15:49:06 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
> 62.188.49.131:58504 67.164.x.x:36457 L=48 S=0x00 I=38710 F=0x4000 T=107 SYN 
> (#93)
> Jan  3 15:49:06 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
> 195.136.148.54:1262 67.164.x.x:36457 L=48 S=0x00 I=11800 F=0x4000 T=112 SYN 
> (#93)


CGIWrap is just a utility wrapper that runs other cgi scripts. It has no control
over what scripts people run with it. You should let some of the traffic through,
perhaps to a dummy service, and see what traffic is sent.

In any case, the google texts all refer to a "remote port: 36457". That would be the 
2443, 45264, 58504, 1262 in the above examples, not the 36457. 

It's likely someone scanning for some vulnerable service, but I am not aware
of anything common that would run on that port.

> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> 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] Why is my router getting bombarded with requests to port 36457?

[Chris R. <tom...@co...>]

Hi Folks,

     I'm not positive about this, but I'm getting a zillion hits on my 
linux router from random places
to port 36457.  When I look that up in Google, CGIWrap comes up in the text 
of the articles.
Can anyone explain this?

Thx, Chris

The log entries look like this:

Jan  3 15:49:05 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
201.128.119.69:2443 67.164.x.x:36457 L=48 S=0x00 I=20105 F=0x4000 T=114 SYN 
(#93)
Jan  3 15:49:05 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
84.84.10.197:45264 67.164.x.x:36457 L=48 S=0x00 I=47078 F=0x4000 T=111 SYN 
(#93)
Jan  3 15:49:06 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
62.188.49.131:58504 67.164.x.x:36457 L=48 S=0x00 I=38710 F=0x4000 T=107 SYN 
(#93)
Jan  3 15:49:06 lp486 kernel: Packet log: input DENY eth1 PROTO=6 
195.136.148.54:1262 67.164.x.x:36457 L=48 S=0x00 I=11800 F=0x4000 T=112 SYN 
(#93)

RE: [cgiwrap-users] cgiwrap and index.php

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

No, there isn't currently any way to do that, but it sure seems like a
worthwhile feature request.

I'll take a look and see if I can come up with something that would add
that functionality.=20

-- 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 Isabelle Moullet
> Sent: Monday, November 29, 2004 10:45 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] cgiwrap and index.php
>=20
> Bonjour,=20
>=20
> I am using cgiwrap 3.7. I got a problem when I request an URL such as=20
>=20
> http://myhost/cgi-bin/cgiwrap/user/dir_path=20
>=20
> where dir_path is a directory path relative to the user Home=20
> directory .
> There is no filename in this URL.
> Indeed I get the response.=20
> Script is not a regular file.=20
>=20
> Is there a way to tell cgiwrap to use index.php if no=20
> filename is given in
> the URL as it is the case for normal html documents?=20
>=20
> My scripts are all located in a specific directory .=20
>=20
> Thanks for your help=20
>=20
>=20
> ********************************************
> Isabelle Moullet
> Centre Informatique UNIL
> College Propedeutique 2
> CH 1015 Lausanne
> Tel: +41 21 692 22 23
> **************************
> Help Desk du Centre informatique: Email: hel...@un...
> (lundi au vendredi 8h30 - 17h00)    Tel:   021 692 22 11
> ********************************************
>=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.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20
>=20

[cgiwrap-users] cgiwrap and index.php

[Isabelle M. <Isa...@un...>]

Bonjour, 

I am using cgiwrap 3.7. I got a problem when I request an URL such as 

http://myhost/cgi-bin/cgiwrap/user/dir_path 

where dir_path is a directory path relative to the user Home directory .
There is no filename in this URL.
Indeed I get the response. 
Script is not a regular file. 

Is there a way to tell cgiwrap to use index.php if no filename is given in
the URL as it is the case for normal html documents? 

My scripts are all located in a specific directory . 

Thanks for your help 


********************************************
Isabelle Moullet
Centre Informatique UNIL
College Propedeutique 2
CH 1015 Lausanne
Tel: +41 21 692 22 23
**************************
Help Desk du Centre informatique: Email: hel...@un...
(lundi au vendredi 8h30 - 17h00)    Tel:   021 692 22 11
********************************************

RE: [cgiwrap-users] CreateInterpreterARGV Broken?

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

I don't see any functional difference between the two forms you've
listed. The "filename" isn't restricted to being just the portion
without the fully qualified path, and in general, it's much less useful
since then the app has no idea how it was invoked in $0.=20

Now, granted, in this case, it's never going to see that value, so it
probably doesn't matter much.=20

I can certainly strip out the path, but I'd like to hear from some other
users before making that change, cause it doesn't seem like it should
have any impact on the behavior.

-- 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 ms...@fr...
> Sent: Friday, October 22, 2004 12:55 AM
> To: cgiwrap
> Subject: Re: [cgiwrap-users] CreateInterpreterARGV Broken?
>=20
> Thanks Nathan! It works. However, I think it still sets ARGV[0]=20
> incorrectly; compare:
>=20
> X Behavior:
>=20
> 	[...]
> 	Executing: '/usr/bin/php'
> 	Arguments:
> 		0: '/usr/bin/php'
> 		1: 'index.php'
>=20
> 	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
> 	[...]
>=20
> X Code:
>=20
>          [...]
>          temp[0] =3D interp;
>          [...]
>=20
> Y Behavior:
>=20
> 	[...]
> 	Executing: '/usr/bin/php'
> 	Arguments:
> 		0: 'php'
> 		1: 'index.php'
>=20
> 	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
> 	[...]
>=20
> Y Code:
>=20
> 	[...]
>          /* Set the first argument to the file name being=20
> executed. From=20
> the
>             execv man page: "The first argument, by=20
> convention, should=20
> point to
>             the file name associated with the file being executed." */
>          execArgv[0] =3D strrchr(execPath, '/');
>          if (execArgv[0] !=3D NULL) {
>                  /* Skip the '/'. */
>                  execArgv[0]++;
>          } else {
>                  /* If the executable's path doesn't contain=20
> a '/', then=20
> it is
>                     its file name. */
>                  execArgv[0] =3D execPath;
>          }
>          /* Allocate memory for the file name. */
>          execArgv[0] =3D strdup(execArgv[0]);
>          [...]
>=20
> Jack
>=20
> On Oct 13, 2004, at 6:14 PM, Nathan Neulinger wrote:
>=20
> > I've applied another update that makes it only use the last=20
> component.
> >
> > However, I'd appreciate your thoughts on whether a fully=20
> specified path
> > would be acceptable. It seems to me that it would be better=20
> to do that
> > so that $0 in the script would be a fully specified path.
> >
> > -- Nathan
> >
> > On Wed, Oct 13, 2004 at 05:42:54PM -0700,=20
> ms...@fr... wrote:
> >> w00t! Thanks for updating CGIWrap!
> >>
> >> Unfortunately, it still seems not to work quite right; I=20
> keep seeing:
> >>
> >>
> >> Changing current directory to '/home/me/public_html/foo/bar'
> >> Executing: '/usr/bin/php'
> >> Arguments:
> >> 	0: '/usr/bin/php'
> >> 	1: '/bar/index.php'
> >>
> >> 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: /bar/index.php.
> >>
> >>
> >> I think this is because the current working directory is=20
> bar, so php
> >> should be opening index.php, instead of /bar/index.php. From=20
> >> cgiwrap.c:
> >>
> >>
> >> /* Change to the directory the cgi script is in */
> >> ChangeToCGIDir(scriptPath);
> >>
> >>
> >> This patch for CreateInterpreterARGV works for me:
> >> http://www.sfu.ca/~jdbates/cgiwrap/patch
> >>
> >> Thanks Nathan!
> >>
> >> Jack
> >>
> >> On Oct 7, 2004, at 3:30 PM, Nathan Neulinger wrote:
> >>
> >>> Ok, I understand what's going on a little better... Looks=20
> like ARGV
> >>> building is broken for both regular AND interpreted scripts.
> >>>
> >>> argv[1] below shouldn't be script.php, it should be=20
> >>> path/to/script.php
> >>>
> >>> it should only be script.php if the script is in the main=20
> cgi-bin/=20
> >>> dir
> >>> under public_html.
> >>>
> >>> I'm just committed a patch for this to cgiwrap cvs repository.
> >>>
> >>> Can you and Pierre both check out whether the new=20
> behavior seems more
> >>> appropriate and correctly functional to you? It definately looks
> >>> like it is more correct to me, but may still not properly=20
> meet your
> >>> needs.
> >>>
> >>> -- Nathan
> >>>
> >>> On Thu, Oct 07, 2004 at 05:01:40PM -0500, Neulinger, Nathan wrote:
> >>>> I definately like the char **execArgv change, but I=20
> don't like the
> >>>> introduced dependence on stdarg, even though it does enable some
> >>>> easier
> >>>> debugging.
> >>>>
> >>>> I'll look into applying a modified version of the patch with
> >>>> the behavior you have described.
> >>>>
> >>>> What happens when the path to the script has multiple elements?=20
> >>>> i.e. a
> >>>> script that is accessed via /userid/somedir/somescript.php.
> >>>>
> >>>> -- Nathan
> >>>>
> >>>> On Thu, Oct 07, 2004 at 03:01:27PM -0500, ms...@fr...=20
> >>>> wrote:
> >>>>>   What do you think of this patch?
> >>>>>   http://www.sfu.ca/~jdbates/cgiwrap/patch
> >>>>>   It shows, in the debug information, that when
> >>>>>   interPath=3D"/path/to/interpreter" &=20
> scrStr=3D"path/to/script.php",
> >>>>>   CreateInterpreterARGV creates the following argument array:
> >>>>>   0: ""
> >>>>>   1: "/script.php"
> >>>>>   I have verified that, given the same interPath & scrStr, the
> >>>>> following
> >>>>>   argument array is compatible with the CLI & CGI:
> >>>>>   0: "interpreter"
> >>>>>   1: "script.php"
> >>>>>   So  I  suggest  changing  CreateInterpreterARGV  to create an
> >>>>> argument
> >>>>>   array
> >>>>>   consisting  of  the  last  element  of  interpreter's  path
> >>>>> (without a
> >>>>>   leading
> >>>>>   /) & the last element of the script's path (without a=20
> leading /).
> >>>>> I
> >>>>>   suspect this is CreateInterpreterARGV's intended=20
> behavior anyway.
> >>>>>      Thanks  so much, Nathan, for maintaining CGIWrap!=20
> I use it all
> >>>>> over
> >>>>>   the
> >>>>>   place; there's no tool like it : )
> >>>>>   Jack
> >>>>>   On Oct 7, 2004, at 5:46 AM, Nathan Neulinger wrote:
> >>>>>> Can  you suggest changes that would be compatible with=20
> both the=20
> >>>>>> cli
> >>>>>   and
> >>>>>> the  cgi?  If  we  can  come  up  with something that doesn't=20
> >>>>>> break
> >>>>>   existing
> >>>>>> usage and fixes the problem you're seeing, I'll be=20
> happy to apply=20
> >>>>>> it
> >>>>>> and
> >>>>>> do a new release.
> >>>>>>
> >>>>>> Pierre - what if any patches are you maintaining in=20
> debian against
> >>>>>> cgiwrap? Anything that should be applied to the main package?
> >>>>>>
> >>>>>> -- Nathan
> >>>>>>
> >>>>>> On  Wed,  Oct  06,  2004  at 09:51:29PM -0700,=20
> >>>>>> ms...@fr...
> >>>>>   wrote:
> >>>>>>> On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> On  Wed,  Oct  06, 2004 at 10:25:50AM -0700,=20
> >>>>>>>> ms...@fr...
> >>>>>   wrote:
> >>>>>>>> [...]
> >>>>>>>>> Turns  out  the problem was that the Debian CGIWrap package=20
> >>>>>>>>> uses
> >>>>>   the
> >>>>>>>>> PHP4
> >>>>>>>>> CLI instead of the PHP4 CGI (presumably to keep=20
> interpreters=20
> >>>>>>>>> out
> >>>>>   of
> >>>>>>>>> the
> >>>>>>>>> webroot). I guess the CGI uses environment=20
> variables to locate
> >>>>>>>>> scripts,
> >>>>>>>>> so is unaffected by the argument array.
> >>>>>>>>
> >>>>>>>> I  am maintaining the Debian package of cgiwrap.=20
> What package=20
> >>>>>>>> are
> >>>>>   you
> >>>>>>>> using?
> >>>>>>>
> >>>>>>> Thank you for maintaining the Debian CGIWrap=20
> packages, Pierre;=20
> >>>>>>> I'm
> >>>>>>> glad
> >>>>>>> they are part of the distribution!
> >>>>>>>
> >>>>>>> Unfortunately, I observe that the php-cgiwrap package=20
> is broken=20
> >>>>>>> in
> >>>>>>> unstable.  It  is  broken  because  /usr/bin/php4  is=20
>  provided=20
> >>>>>>> by
> >>>>>   php4-cli,
> >>>>>>> instead of php4-cgi, & CGIWrap's=20
> CreateInterpreterARGV produces=20
> >>>>>>> an
> >>>>>>> argument array which breaks the PHP4 CLI (unlike the=20
> PHP4 CGI).
> >>>>>>>
> >>>>>>> I do not suggest repackaging CGIWrap to use=20
> /usr/lib/cgi-bin/php4
> >>>>>>> (provided by the php4-cgi package) since this path=20
> published by=20
> >>>>>>> the
> >>>>>>> web
> >>>>>>> server. Instead, I suggest fixing CreateInterpreterARGV /
> >>>>>>> StripPathComponents (in util.c) to produce an argument array=20
> >>>>>>> which
> >>>>>   may
> >>>>>>> be used by PHP4 CLI.
> >>>>>>>
> >>>>>>> Thanks again!
> >>>>>>>
> >>>>>>> Jack
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -------------------------------------------------------
> >>>>>>> This SF.net email is sponsored by: IT Product Guide on
> >>>>>>> ITManagersJournal
> >>>>>>> Use IT products in your business? Tell us what you=20
> think of them.
> >>>>>>> Give us
> >>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to=20
> >>>>>>> find
> >>>>>>> out more
> >>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>>>>>> _______________________________________________
> >>>>>>> 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-4841
> >>>>>> UMR Information Technology             Fax: (573) 341-4216
> >>>>>>
> >>>>>>
> >>>>>   -------------------------------------------------------
> >>>>>   This   SF.net   email   is   sponsored   by:   IT   Product
> >>>>> Guide  on
> >>>>>   ITManagersJournal
> >>>>>   Use IT products in your business? Tell us what you=20
> think of them.
> >>>>> Give
> >>>>>   us
> >>>>>   Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> >>>>> find out
> >>>>>   more
> >>>>>   http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>>>>   _______________________________________________
> >>>>>   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-4841
> >>>> UMR Information Technology             Fax: (573) 341-4216
> >>> -- Nathan
> >>>
> >>> ------------------------------------------------------------
> >>> Nathan Neulinger                       EMail:  nn...@um...
> >>> University of Missouri - Rolla         Phone: (573) 341-6679
> >>> UMR Information Technology             Fax: (573) 341-4216
> >>>
> >>>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: IT Product Guide on=20
> >> ITManagersJournal
> >> Use IT products in your business? Tell us what you think of them.=20
> >> Give us
> >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find=20
> >> out more
> >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >> _______________________________________________
> >> 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-4841
> > UMR Information Technology             Fax: (573) 341-4216
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on=20
> ITManagersJournal
> Use IT products in your business? Tell us what you think of=20
> them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to=20
> find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20
>=20

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

Thanks Nathan! It works. However, I think it still sets ARGV[0] 
incorrectly; compare:

X Behavior:

	[...]
	Executing: '/usr/bin/php'
	Arguments:
		0: '/usr/bin/php'
		1: 'index.php'

	Output of script follows:
	=====================================================
	[...]

X Code:

         [...]
         temp[0] = interp;
         [...]

Y Behavior:

	[...]
	Executing: '/usr/bin/php'
	Arguments:
		0: 'php'
		1: 'index.php'

	Output of script follows:
	=====================================================
	[...]

Y Code:

	[...]
         /* Set the first argument to the file name being executed. From 
the
            execv man page: "The first argument, by convention, should 
point to
            the file name associated with the file being executed." */
         execArgv[0] = strrchr(execPath, '/');
         if (execArgv[0] != NULL) {
                 /* Skip the '/'. */
                 execArgv[0]++;
         } else {
                 /* If the executable's path doesn't contain a '/', then 
it is
                    its file name. */
                 execArgv[0] = execPath;
         }
         /* Allocate memory for the file name. */
         execArgv[0] = strdup(execArgv[0]);
         [...]

Jack

On Oct 13, 2004, at 6:14 PM, Nathan Neulinger wrote:

> I've applied another update that makes it only use the last component.
>
> However, I'd appreciate your thoughts on whether a fully specified path
> would be acceptable. It seems to me that it would be better to do that
> so that $0 in the script would be a fully specified path.
>
> -- Nathan
>
> On Wed, Oct 13, 2004 at 05:42:54PM -0700, ms...@fr... wrote:
>> w00t! Thanks for updating CGIWrap!
>>
>> Unfortunately, it still seems not to work quite right; I keep seeing:
>>
>>
>> Changing current directory to '/home/me/public_html/foo/bar'
>> Executing: '/usr/bin/php'
>> Arguments:
>> 	0: '/usr/bin/php'
>> 	1: '/bar/index.php'
>>
>> Output of script follows:
>> =====================================================
>> Could not open input file: /bar/index.php.
>>
>>
>> I think this is because the current working directory is bar, so php
>> should be opening index.php, instead of /bar/index.php. From 
>> cgiwrap.c:
>>
>>
>> /* Change to the directory the cgi script is in */
>> ChangeToCGIDir(scriptPath);
>>
>>
>> This patch for CreateInterpreterARGV works for me:
>> http://www.sfu.ca/~jdbates/cgiwrap/patch
>>
>> Thanks Nathan!
>>
>> Jack
>>
>> On Oct 7, 2004, at 3:30 PM, Nathan Neulinger wrote:
>>
>>> Ok, I understand what's going on a little better... Looks like ARGV
>>> building is broken for both regular AND interpreted scripts.
>>>
>>> argv[1] below shouldn't be script.php, it should be 
>>> path/to/script.php
>>>
>>> it should only be script.php if the script is in the main cgi-bin/ 
>>> dir
>>> under public_html.
>>>
>>> I'm just committed a patch for this to cgiwrap cvs repository.
>>>
>>> Can you and Pierre both check out whether the new behavior seems more
>>> appropriate and correctly functional to you? It definately looks
>>> like it is more correct to me, but may still not properly meet your
>>> needs.
>>>
>>> -- Nathan
>>>
>>> On Thu, Oct 07, 2004 at 05:01:40PM -0500, Neulinger, Nathan wrote:
>>>> I definately like the char **execArgv change, but I don't like the
>>>> introduced dependence on stdarg, even though it does enable some
>>>> easier
>>>> debugging.
>>>>
>>>> I'll look into applying a modified version of the patch with
>>>> the behavior you have described.
>>>>
>>>> What happens when the path to the script has multiple elements? 
>>>> i.e. a
>>>> script that is accessed via /userid/somedir/somescript.php.
>>>>
>>>> -- Nathan
>>>>
>>>> On Thu, Oct 07, 2004 at 03:01:27PM -0500, ms...@fr... 
>>>> wrote:
>>>>>   What do you think of this patch?
>>>>>   http://www.sfu.ca/~jdbates/cgiwrap/patch
>>>>>   It shows, in the debug information, that when
>>>>>   interPath="/path/to/interpreter" & scrStr="path/to/script.php",
>>>>>   CreateInterpreterARGV creates the following argument array:
>>>>>   0: ""
>>>>>   1: "/script.php"
>>>>>   I have verified that, given the same interPath & scrStr, the
>>>>> following
>>>>>   argument array is compatible with the CLI & CGI:
>>>>>   0: "interpreter"
>>>>>   1: "script.php"
>>>>>   So  I  suggest  changing  CreateInterpreterARGV  to create an
>>>>> argument
>>>>>   array
>>>>>   consisting  of  the  last  element  of  interpreter's  path
>>>>> (without a
>>>>>   leading
>>>>>   /) & the last element of the script's path (without a leading /).
>>>>> I
>>>>>   suspect this is CreateInterpreterARGV's intended behavior anyway.
>>>>>      Thanks  so much, Nathan, for maintaining CGIWrap! I use it all
>>>>> over
>>>>>   the
>>>>>   place; there's no tool like it : )
>>>>>   Jack
>>>>>   On Oct 7, 2004, at 5:46 AM, Nathan Neulinger wrote:
>>>>>> Can  you suggest changes that would be compatible with both the 
>>>>>> cli
>>>>>   and
>>>>>> the  cgi?  If  we  can  come  up  with something that doesn't 
>>>>>> break
>>>>>   existing
>>>>>> usage and fixes the problem you're seeing, I'll be happy to apply 
>>>>>> it
>>>>>> and
>>>>>> do a new release.
>>>>>>
>>>>>> Pierre - what if any patches are you maintaining in debian against
>>>>>> cgiwrap? Anything that should be applied to the main package?
>>>>>>
>>>>>> -- Nathan
>>>>>>
>>>>>> On  Wed,  Oct  06,  2004  at 09:51:29PM -0700, 
>>>>>> ms...@fr...
>>>>>   wrote:
>>>>>>> On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On  Wed,  Oct  06, 2004 at 10:25:50AM -0700, 
>>>>>>>> ms...@fr...
>>>>>   wrote:
>>>>>>>> [...]
>>>>>>>>> Turns  out  the problem was that the Debian CGIWrap package 
>>>>>>>>> uses
>>>>>   the
>>>>>>>>> PHP4
>>>>>>>>> CLI instead of the PHP4 CGI (presumably to keep interpreters 
>>>>>>>>> out
>>>>>   of
>>>>>>>>> the
>>>>>>>>> webroot). I guess the CGI uses environment variables to locate
>>>>>>>>> scripts,
>>>>>>>>> so is unaffected by the argument array.
>>>>>>>>
>>>>>>>> I  am maintaining the Debian package of cgiwrap. What package 
>>>>>>>> are
>>>>>   you
>>>>>>>> using?
>>>>>>>
>>>>>>> Thank you for maintaining the Debian CGIWrap packages, Pierre; 
>>>>>>> I'm
>>>>>>> glad
>>>>>>> they are part of the distribution!
>>>>>>>
>>>>>>> Unfortunately, I observe that the php-cgiwrap package is broken 
>>>>>>> in
>>>>>>> unstable.  It  is  broken  because  /usr/bin/php4  is  provided 
>>>>>>> by
>>>>>   php4-cli,
>>>>>>> instead of php4-cgi, & CGIWrap's CreateInterpreterARGV produces 
>>>>>>> an
>>>>>>> argument array which breaks the PHP4 CLI (unlike the PHP4 CGI).
>>>>>>>
>>>>>>> I do not suggest repackaging CGIWrap to use /usr/lib/cgi-bin/php4
>>>>>>> (provided by the php4-cgi package) since this path published by 
>>>>>>> the
>>>>>>> web
>>>>>>> server. Instead, I suggest fixing CreateInterpreterARGV /
>>>>>>> StripPathComponents (in util.c) to produce an argument array 
>>>>>>> which
>>>>>   may
>>>>>>> be used by PHP4 CLI.
>>>>>>>
>>>>>>> Thanks again!
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------
>>>>>>> This SF.net email is sponsored by: IT Product Guide on
>>>>>>> ITManagersJournal
>>>>>>> Use IT products in your business? Tell us what you think of them.
>>>>>>> Give us
>>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to 
>>>>>>> find
>>>>>>> out more
>>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>>>> _______________________________________________
>>>>>>> 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-4841
>>>>>> UMR Information Technology             Fax: (573) 341-4216
>>>>>>
>>>>>>
>>>>>   -------------------------------------------------------
>>>>>   This   SF.net   email   is   sponsored   by:   IT   Product
>>>>> Guide  on
>>>>>   ITManagersJournal
>>>>>   Use IT products in your business? Tell us what you think of them.
>>>>> Give
>>>>>   us
>>>>>   Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
>>>>> find out
>>>>>   more
>>>>>   http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>>   _______________________________________________
>>>>>   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-4841
>>>> UMR Information Technology             Fax: (573) 341-4216
>>> -- Nathan
>>>
>>> ------------------------------------------------------------
>>> Nathan Neulinger                       EMail:  nn...@um...
>>> University of Missouri - Rolla         Phone: (573) 341-6679
>>> UMR Information Technology             Fax: (573) 341-4216
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on 
>> ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. 
>> Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>> out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> 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-4841
> UMR Information Technology             Fax: (573) 341-4216
>
>

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

w00t! Thanks for updating CGIWrap!

Unfortunately, it still seems not to work quite right; I keep seeing:


Changing current directory to '/home/me/public_html/foo/bar'
Executing: '/usr/bin/php'
Arguments:
	0: '/usr/bin/php'
	1: '/bar/index.php'

Output of script follows:
=====================================================
Could not open input file: /bar/index.php.


I think this is because the current working directory is bar, so php 
should be opening index.php, instead of /bar/index.php. From cgiwrap.c:


/* Change to the directory the cgi script is in */
ChangeToCGIDir(scriptPath);


This patch for CreateInterpreterARGV works for me: 
http://www.sfu.ca/~jdbates/cgiwrap/patch

Thanks Nathan!

Jack

On Oct 7, 2004, at 3:30 PM, Nathan Neulinger wrote:

> Ok, I understand what's going on a little better... Looks like ARGV
> building is broken for both regular AND interpreted scripts.
>
> argv[1] below shouldn't be script.php, it should be path/to/script.php
>
> it should only be script.php if the script is in the main cgi-bin/ dir
> under public_html.
>
> I'm just committed a patch for this to cgiwrap cvs repository.
>
> Can you and Pierre both check out whether the new behavior seems more
> appropriate and correctly functional to you? It definately looks
> like it is more correct to me, but may still not properly meet your 
> needs.
>
> -- Nathan
>
> On Thu, Oct 07, 2004 at 05:01:40PM -0500, Neulinger, Nathan wrote:
>> I definately like the char **execArgv change, but I don't like the
>> introduced dependence on stdarg, even though it does enable some 
>> easier
>> debugging.
>>
>> I'll look into applying a modified version of the patch with
>> the behavior you have described.
>>
>> What happens when the path to the script has multiple elements? i.e. a
>> script that is accessed via /userid/somedir/somescript.php.
>>
>> -- Nathan
>>
>> On Thu, Oct 07, 2004 at 03:01:27PM -0500, ms...@fr... wrote:
>>>    What do you think of this patch?
>>>    http://www.sfu.ca/~jdbates/cgiwrap/patch
>>>    It shows, in the debug information, that when
>>>    interPath="/path/to/interpreter" & scrStr="path/to/script.php",
>>>    CreateInterpreterARGV creates the following argument array:
>>>    0: ""
>>>    1: "/script.php"
>>>    I have verified that, given the same interPath & scrStr, the 
>>> following
>>>    argument array is compatible with the CLI & CGI:
>>>    0: "interpreter"
>>>    1: "script.php"
>>>    So  I  suggest  changing  CreateInterpreterARGV  to create an 
>>> argument
>>>    array
>>>    consisting  of  the  last  element  of  interpreter's  path 
>>> (without a
>>>    leading
>>>    /) & the last element of the script's path (without a leading /). 
>>> I
>>>    suspect this is CreateInterpreterARGV's intended behavior anyway.
>>>       Thanks  so much, Nathan, for maintaining CGIWrap! I use it all 
>>> over
>>>    the
>>>    place; there's no tool like it : )
>>>    Jack
>>>    On Oct 7, 2004, at 5:46 AM, Nathan Neulinger wrote:
>>>>  Can  you suggest changes that would be compatible with both the cli
>>>    and
>>>>  the  cgi?  If  we  can  come  up  with something that doesn't break
>>>    existing
>>>> usage and fixes the problem you're seeing, I'll be happy to apply it
>>>> and
>>>> do a new release.
>>>>
>>>> Pierre - what if any patches are you maintaining in debian against
>>>> cgiwrap? Anything that should be applied to the main package?
>>>>
>>>> -- Nathan
>>>>
>>>>  On  Wed,  Oct  06,  2004  at 09:51:29PM -0700, ms...@fr...
>>>    wrote:
>>>>> On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>  On  Wed,  Oct  06, 2004 at 10:25:50AM -0700, ms...@fr...
>>>    wrote:
>>>>>> [...]
>>>>>>>  Turns  out  the problem was that the Debian CGIWrap package uses
>>>    the
>>>>>>> PHP4
>>>>>>>  CLI instead of the PHP4 CGI (presumably to keep interpreters out
>>>    of
>>>>>>> the
>>>>>>> webroot). I guess the CGI uses environment variables to locate
>>>>>>> scripts,
>>>>>>> so is unaffected by the argument array.
>>>>>>
>>>>>>  I  am maintaining the Debian package of cgiwrap. What package are
>>>    you
>>>>>> using?
>>>>>
>>>>> Thank you for maintaining the Debian CGIWrap packages, Pierre; I'm
>>>>> glad
>>>>> they are part of the distribution!
>>>>>
>>>>> Unfortunately, I observe that the php-cgiwrap package is broken in
>>>>>  unstable.  It  is  broken  because  /usr/bin/php4  is  provided by
>>>    php4-cli,
>>>>> instead of php4-cgi, & CGIWrap's CreateInterpreterARGV produces an
>>>>> argument array which breaks the PHP4 CLI (unlike the PHP4 CGI).
>>>>>
>>>>> I do not suggest repackaging CGIWrap to use /usr/lib/cgi-bin/php4
>>>>> (provided by the php4-cgi package) since this path published by the
>>>>> web
>>>>> server. Instead, I suggest fixing CreateInterpreterARGV /
>>>>>  StripPathComponents (in util.c) to produce an argument array which
>>>    may
>>>>> be used by PHP4 CLI.
>>>>>
>>>>> Thanks again!
>>>>>
>>>>> Jack
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.net email is sponsored by: IT Product Guide on
>>>>> ITManagersJournal
>>>>> Use IT products in your business? Tell us what you think of them.
>>>>> Give us
>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>>>> out more
>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>> _______________________________________________
>>>>> 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-4841
>>>> UMR Information Technology             Fax: (573) 341-4216
>>>>
>>>>
>>>    -------------------------------------------------------
>>>    This   SF.net   email   is   sponsored   by:   IT   Product  
>>> Guide  on
>>>    ITManagersJournal
>>>    Use IT products in your business? Tell us what you think of them. 
>>> Give
>>>    us
>>>    Your Opinions, Get Free ThinkGeek Gift Certificates! Click to 
>>> find out
>>>    more
>>>    http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>    _______________________________________________
>>>    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-4841
>> UMR Information Technology             Fax: (573) 341-4216
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-6679
> UMR Information Technology             Fax: (573) 341-4216
>
>

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

Ok, I understand what's going on a little better... Looks like ARGV
building is broken for both regular AND interpreted scripts.

argv[1] below shouldn't be script.php, it should be path/to/script.php

it should only be script.php if the script is in the main cgi-bin/ dir
under public_html. 

I'm just committed a patch for this to cgiwrap cvs repository.

Can you and Pierre both check out whether the new behavior seems more
appropriate and correctly functional to you? It definately looks 
like it is more correct to me, but may still not properly meet your needs.

-- Nathan

On Thu, Oct 07, 2004 at 05:01:40PM -0500, Neulinger, Nathan wrote:
> I definately like the char **execArgv change, but I don't like the
> introduced dependence on stdarg, even though it does enable some easier
> debugging.
> 
> I'll look into applying a modified version of the patch with
> the behavior you have described. 
> 
> What happens when the path to the script has multiple elements? i.e. a
> script that is accessed via /userid/somedir/somescript.php. 
> 
> -- Nathan
> 
> On Thu, Oct 07, 2004 at 03:01:27PM -0500, ms...@fr... wrote:
> >    What do you think of this patch?
> >    http://www.sfu.ca/~jdbates/cgiwrap/patch
> >    It shows, in the debug information, that when
> >    interPath="/path/to/interpreter" & scrStr="path/to/script.php",
> >    CreateInterpreterARGV creates the following argument array:
> >    0: ""
> >    1: "/script.php"
> >    I have verified that, given the same interPath & scrStr, the following
> >    argument array is compatible with the CLI & CGI:
> >    0: "interpreter"
> >    1: "script.php"
> >    So  I  suggest  changing  CreateInterpreterARGV  to create an argument
> >    array
> >    consisting  of  the  last  element  of  interpreter's  path (without a
> >    leading
> >    /) & the last element of the script's path (without a leading /). I
> >    suspect this is CreateInterpreterARGV's intended behavior anyway.
> >       Thanks  so much, Nathan, for maintaining CGIWrap! I use it all over
> >    the
> >    place; there's no tool like it : )
> >    Jack
> >    On Oct 7, 2004, at 5:46 AM, Nathan Neulinger wrote:
> >    >  Can  you suggest changes that would be compatible with both the cli
> >    and
> >    >  the  cgi?  If  we  can  come  up  with something that doesn't break
> >    existing
> >    > usage and fixes the problem you're seeing, I'll be happy to apply it
> >    > and
> >    > do a new release.
> >    >
> >    > Pierre - what if any patches are you maintaining in debian against
> >    > cgiwrap? Anything that should be applied to the main package?
> >    >
> >    > -- Nathan
> >    >
> >    >  On  Wed,  Oct  06,  2004  at 09:51:29PM -0700, ms...@fr...
> >    wrote:
> >    >> On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:
> >    >>
> >    >>> Hello,
> >    >>>
> >    >>>  On  Wed,  Oct  06, 2004 at 10:25:50AM -0700, ms...@fr...
> >    wrote:
> >    >>> [...]
> >    >>>>  Turns  out  the problem was that the Debian CGIWrap package uses
> >    the
> >    >>>> PHP4
> >    >>>>  CLI instead of the PHP4 CGI (presumably to keep interpreters out
> >    of
> >    >>>> the
> >    >>>> webroot). I guess the CGI uses environment variables to locate
> >    >>>> scripts,
> >    >>>> so is unaffected by the argument array.
> >    >>>
> >    >>>  I  am maintaining the Debian package of cgiwrap. What package are
> >    you
> >    >>> using?
> >    >>
> >    >> Thank you for maintaining the Debian CGIWrap packages, Pierre; I'm
> >    >> glad
> >    >> they are part of the distribution!
> >    >>
> >    >> Unfortunately, I observe that the php-cgiwrap package is broken in
> >    >>  unstable.  It  is  broken  because  /usr/bin/php4  is  provided by
> >    php4-cli,
> >    >> instead of php4-cgi, & CGIWrap's CreateInterpreterARGV produces an
> >    >> argument array which breaks the PHP4 CLI (unlike the PHP4 CGI).
> >    >>
> >    >> I do not suggest repackaging CGIWrap to use /usr/lib/cgi-bin/php4
> >    >> (provided by the php4-cgi package) since this path published by the
> >    >> web
> >    >> server. Instead, I suggest fixing CreateInterpreterARGV /
> >    >>  StripPathComponents (in util.c) to produce an argument array which
> >    may
> >    >> be used by PHP4 CLI.
> >    >>
> >    >> Thanks again!
> >    >>
> >    >> Jack
> >    >>
> >    >>
> >    >>
> >    >> -------------------------------------------------------
> >    >> This SF.net email is sponsored by: IT Product Guide on
> >    >> ITManagersJournal
> >    >> Use IT products in your business? Tell us what you think of them.
> >    >> Give us
> >    >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
> >    >> out more
> >    >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >    >> _______________________________________________
> >    >> 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-4841
> >    > UMR Information Technology             Fax: (573) 341-4216
> >    >
> >    >
> >    -------------------------------------------------------
> >    This   SF.net   email   is   sponsored   by:   IT   Product  Guide  on
> >    ITManagersJournal
> >    Use IT products in your business? Tell us what you think of them. Give
> >    us
> >    Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> >    more
> >    http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >    _______________________________________________
> >    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-4841
> UMR Information Technology             Fax: (573) 341-4216
-- Nathan

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

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

What do you think of this patch? 
http://www.sfu.ca/~jdbates/cgiwrap/patch

It shows, in the debug information, that when 
interPath="/path/to/interpreter" & scrStr="path/to/script.php", 
CreateInterpreterARGV creates the following argument array:

0: ""
1: "/script.php"

I have verified that, given the same interPath & scrStr, the following 
argument array is compatible with the CLI & CGI:

0: "interpreter"
1: "script.php"

So I suggest changing CreateInterpreterARGV to create an argument array 
consisting of the last element of interpreter's path (without a leading 
/) & the last element of the script's path (without a leading /). I 
suspect this is CreateInterpreterARGV's intended behavior anyway.

  Thanks so much, Nathan, for maintaining CGIWrap! I use it all over the 
place; there's no tool like it : )

Jack

On Oct 7, 2004, at 5:46 AM, Nathan Neulinger wrote:

> Can you suggest changes that would be compatible with both the cli and
> the cgi? If we can come up with something that doesn't break existing
> usage and fixes the problem you're seeing, I'll be happy to apply it 
> and
> do a new release.
>
> Pierre - what if any patches are you maintaining in debian against
> cgiwrap? Anything that should be applied to the main package?
>
> -- Nathan
>
> On Wed, Oct 06, 2004 at 09:51:29PM -0700, ms...@fr... wrote:
>> On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:
>>
>>> Hello,
>>>
>>> On Wed, Oct 06, 2004 at 10:25:50AM -0700, ms...@fr... wrote:
>>> [...]
>>>> Turns out the problem was that the Debian CGIWrap package uses the
>>>> PHP4
>>>> CLI instead of the PHP4 CGI (presumably to keep interpreters out of
>>>> the
>>>> webroot). I guess the CGI uses environment variables to locate
>>>> scripts,
>>>> so is unaffected by the argument array.
>>>
>>> I am maintaining the Debian package of cgiwrap. What package are you
>>> using?
>>
>> Thank you for maintaining the Debian CGIWrap packages, Pierre; I'm 
>> glad
>> they are part of the distribution!
>>
>> Unfortunately, I observe that the php-cgiwrap package is broken in
>> unstable. It is broken because /usr/bin/php4 is provided by php4-cli,
>> instead of php4-cgi, & CGIWrap's CreateInterpreterARGV produces an
>> argument array which breaks the PHP4 CLI (unlike the PHP4 CGI).
>>
>> I do not suggest repackaging CGIWrap to use /usr/lib/cgi-bin/php4
>> (provided by the php4-cgi package) since this path published by the 
>> web
>> server. Instead, I suggest fixing CreateInterpreterARGV /
>> StripPathComponents (in util.c) to produce an argument array which may
>> be used by PHP4 CLI.
>>
>> Thanks again!
>>
>> Jack
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on 
>> ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. 
>> Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>> out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> 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-4841
> UMR Information Technology             Fax: (573) 341-4216
>
>

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

On Oct 6, 2004, at 11:58 AM, Pierre Machard wrote:

> Hello,
>
> On Wed, Oct 06, 2004 at 10:25:50AM -0700, ms...@fr... wrote:
> [...]
>> Turns out the problem was that the Debian CGIWrap package uses the 
>> PHP4
>> CLI instead of the PHP4 CGI (presumably to keep interpreters out of 
>> the
>> webroot). I guess the CGI uses environment variables to locate 
>> scripts,
>> so is unaffected by the argument array.
>
> I am maintaining the Debian package of cgiwrap. What package are you
> using?

Thank you for maintaining the Debian CGIWrap packages, Pierre; I'm glad 
they are part of the distribution!

Unfortunately, I observe that the php-cgiwrap package is broken in 
unstable. It is broken because /usr/bin/php4 is provided by php4-cli, 
instead of php4-cgi, & CGIWrap's CreateInterpreterARGV produces an 
argument array which breaks the PHP4 CLI (unlike the PHP4 CGI).

I do not suggest repackaging CGIWrap to use /usr/lib/cgi-bin/php4 
(provided by the php4-cgi package) since this path published by the web 
server. Instead, I suggest fixing CreateInterpreterARGV / 
StripPathComponents (in util.c) to produce an argument array which may 
be used by PHP4 CLI.

Thanks again!

Jack

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

[Pierre M. <pi...@ma...>]

Hello,

On Wed, Oct 06, 2004 at 10:25:50AM -0700, ms...@fr... wrote:
[...]
> Turns out the problem was that the Debian CGIWrap package uses the PHP4=
=20
> CLI instead of the PHP4 CGI (presumably to keep interpreters out of the=
=20
> webroot). I guess the CGI uses environment variables to locate scripts,=
=20
> so is unaffected by the argument array.

I am maintaining the Debian package of cgiwrap. What package are you
using?

I created two packages. php-cgiwrap and cgiwrap. The first one depends on
php4-cgi. The second (cgiwrap) exists only to keep compatibility before
than cgiwrap support php4. I do not understand what you exaclty wrote=20
above. If you want to use php4 with cgiwrap can you please use=20
php-cgiwrap?

I'll be happy if I can resolve the problem you exposed here.

Cheers,
--=20
Pierre Machard
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87

Re: [cgiwrap-users] CreateInterpreterARGV Broken?

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

On Oct 4, 2004, at 4:15 AM, Michael Middleton wrote:

> On 1 Oct 2004 at 19:36, ms...@fr... wrote:
>
>> When running PHPs using CGIWrap, I keep seeing:
>>
>> Output of script follows:
>> =====================================================
>> Could not open input file: /day.php.
>>
>> It seems CreateInterpreterARGV is yielding /day.php, instead of 
>> day.php:
>>
>> temp[1] = StripPathComponents( CountSubDirs(scrStr), scrStr );
>>
>> For a couple days, I thought I was the problem, but on inspection, I
>> think StripPathComponents will always yield a leading /.
>>
>> My principle reason for trying CGIWrap was to run PHPs with users'
>> permissions, so this is a bummer.
>>
>> Say, does interpreter support work for anyone else?
>
> Hello Jack,
>
> I have been using CGIwrap with PHP for some time.
>
> Normally the users acces PHP from public_html in safe mode. I have also
> allowed a CGI-mode that runs the script with the user's permissions.
>
> I had a lot of trouble with CGIwrap and PHP until Nathan included Piotr
> Klaban's patch in the standard distribution (somewhere around version
> 4.6.5).
>
> I compiled CGIwrap with
>  --with-php --with-php-interpreter --with-php-noexec-only
> and PHP with
>  --disable-force-cgi-redirect --enable-discard-path
>
> You do not say how you called your PHP-script. I assume it was with a
> shell start like
>  #!/usr/local/bin/php
>
> Have you tried calling the interprter directly, ie without this line?
>
> You did not say, what OS you are using. My servers run under Solaris 9,
> which is proving to be more and more difficult. Perhaps the trouble ist
> with your OS.

Thanks very much for your help, Michael!

I had been using Debian Linux, unstable. Taking your advice, I tried 
another machine - running SunOS 5.9 - & It worked! Unfortunately, it 
wasn't obvious why.

I wrote this patch for CGIWrap to include information about the 
execution call & argument array CGIWrap makes:

http://www.sfu.ca/~jdbates/cgiwrap/patch

I also wrote a little test, which uses this patch & 
CreateInterpreterARGV to examine how the interpreter is called:

http://www.sfu.ca/~jdbates/cgiwrap/test.c

Turns out the problem was that the Debian CGIWrap package uses the PHP4 
CLI instead of the PHP4 CGI (presumably to keep interpreters out of the 
webroot). I guess the CGI uses environment variables to locate scripts, 
so is unaffected by the argument array.

However, if CreateInterpreterARGV (or StripPathComponents) could be 
fixed to produce a sensible argument array, CGIWrap could work with the 
CLI.

The PHP4 CLI doesn't like this leading /:
---
jablko@wum:~$ SCRIPT_PATH=foo/bar/day.php EXEC_PATH=/usr/bin/php ./test 
| head
Executing: '/usr/bin/php'
Arguments:
         ''
         '/day.php'
Could not open input file: /day.php.
---
But this works:
---
jablko@wum:~$ SCRIPT_PATH=day.php EXEC_PATH=/usr/bin/php ./test | head
Executing: '/usr/bin/php'
Arguments:
         ''
         'day.php'

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
         "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html>
<head>
         <meta http-equiv="content-type" 
content="text/html;charset=UTF-8">
---
I think CreateInterpreterARGV is meant produce an argument array 
containing the last element of the interpreter's path & the last 
element of the script's path - sans /s - in all cases:
---
jablko@wum:~$ SCRIPT_PATH=day.php EXEC_PATH=php ./test | head
Executing: 'php'
Arguments:
         'php'
         'day.php'
---

Thanks!

Jack

[cgiwrap-users] CreateInterpreterARGV Broken?

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

When running PHPs using CGIWrap, I keep seeing:

Output of script follows:
=====================================================
Could not open input file: /day.php.

It seems CreateInterpreterARGV is yielding /day.php, instead of day.php:

temp[1] = StripPathComponents( CountSubDirs(scrStr), scrStr );

For a couple days, I thought I was the problem, but on inspection, I 
think StripPathComponents will always yield a leading /.

My principle reason for trying CGIWrap was to run PHPs with users' 
permissions, so this is a bummer.

Say, does interpreter support work for anyone else?

Best wishes,

Jack

Re: [cgiwrap-users] PATH_TRANSLATED in CGIwrap 3.9

[Mic K. <mi...@ut...>]

Nathan Neulinger <nn...@um...>
>I still have absolutely no idea exactly what this variable is supposed
>to do, and since it has gone through so many iterations of behavior in
>cgiwrap that various people have built applications around, it's hard to
>know whether "broke" really is "working fine" - I think it all depends
>on who you ask.

Gotcha.

>With that in mind, I'm probably not going to apply any more patches
>specifically to address PATH_TRANSLATED, unless either someone can show
>me a specific reliable source justifying the behavior, or if it is a
>patch that can be cleanly "--with-something" to enable it. I think I can
>probably do that for below. Maybe a "--with-cgiwrap37-path-translated"
>option or something like that.

Thanks for the additional background. I think you're right -- whatever
changes made, if any, should be based on a specific reliable source
justifying the behavior. I will look at the code again from this
standpoint.

For the very reason you give, I would even go so far as to recommend
against a --with-something config option; absent a reliable guide,
there is no use providing for more unjustified behavior.

Thanks,

--mic--


-- Mic Kaczmarczik - UT Austin ITS Systems - Unix - m.k...@it...

[cgiwrap-users] PATH_TRANSLATED in CGIwrap 3.9

[Mic K. <mi...@ut...>]

Today we attempted to upgrade our CGIwrap installation from 3.7 to 3.9
- please don't laugh too hard - and immediately ran into a problem.

One user's Perl CGI application uses PATH_TRANSLATED to locate its
Perl library directory.  With 3.7, PATH_TRANSLATED was rewritten to be
the CGI base directory in the user's home directory. In 3.9,
PATH_TRANSLATED is apparently not updated, and remains a path to the
script relative to the Apache server's document root.  So the
application failed.

Shouldn't PATH_TRANSLATED still reflect where the user's CGI program
is?  Since we have not set up to use PHP-CGIwrap support or multi-user
CGI directories, maybe I'm missing something in our configuration.

At any rate, after reviewing the mailing list and the code, I came up
with the following patch to help us keep going. It attempts to behave
like 3.7 did, but only if CGIwrap is executing a CGI program instead
of an interpreted script. Otherwise the rest of the code in
SetPathTranslated() runs as before, to preserve those behavior
changes.

This ham fisted change will probably address our local issue; I
certainly would not pretend to know if it's the right thing to do
overall. So, um, er... any ideas what _would_ be the right thing?

--mic--
----------------------------------------------------------------
--- util.c.dist	2004-09-27 17:10:07.585241000 -0500
+++ util.c	2004-09-27 17:10:07.365241000 -0500
@@ -1399,6 +1399,16 @@
 		/* don't set one if the server didn't */
 		return;
 	}
+
+	/* Hack to act like 3.7 if we are dealing with a CGI program */
+	if (!Context.interpreted_script && Context.origPathInfo) {
+		buf = (char *) SafeMalloc( strlen(cgiBaseDir) + strlen("PATH_TRANSLATED") + 5, 
+			"new PATH_TRANSLATED environment variable");
+		sprintf(buf, "%s=%s", "PATH_TRANSLATED", cgiBaseDir); 
+		SafePutenv(buf, "new PATH_TRANSLATED environment variable");
+		return;
+	}
+
 	new_pt = strdup(old_pt);
 
 	old_pi = Context.origPathInfo;






-- Mic Kaczmarczik - UT Austin ITS Systems - Unix - m.k...@it...

[cgiwrap-users] http://server/~user/cgi-bin & cgiwrap?

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

I use mod_rewrite & cgiwrap to run CGIs: 
http://www.sfu.ca/~jdbates/cgiwrap/httpd.conf

It works great - I can run CGIs at http://server/~user/cgi-bin - except 
for links to http://server/cgi-bin/cgiwrap/user. Running CGIs at 
http://server/cgi-bin/cgiwrap/user works, but I'd rather my use of 
cgiwrap were fully transparent - &, more importantly, it breaks 
relative links to images, CSS, etc.

So, the first page of a CGI at http://server/~user/cgi-bin works great 
- but all links lead to http://server/cgi-bin/cgiwrap/user, where all 
images & CSS are broken.

I think Apache & cgiwrap are capable of anything, but I can't figure 
out how to avoid this problem. How do I trick CGIs into thinking 
they're being run at http://server/~user/cgi-bin, while using cgiwrap?

Thanks so much for any help!

Jack

RE: [cgiwrap-users] CGIWRAP and Nagios

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

I don't have time to walk through it completely, but basically you'd
need to:

set up a userid for nagios
create a homedir for that user with public_html/cgi-bin as a symlink to
the main nagios cgi-bin dir.=20
run with the URL /cgi-bin/cgiwrap/userid/scriptname to get it working
then work on the shortened URL's if you don't like the full syntax.=20

I was pretty sure that nagios specifically mentioned cgiwrap support
with instructions on how to get it set up, might want to check those
over.=20


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

> -----Original Message-----
> From: Horvath Tamas [mailto:zs...@ax...]=20
> Sent: Wednesday, August 18, 2004 2:19 PM
> To: Neulinger, Nathan
> Cc: cgiwrap
> Subject: Re: [cgiwrap-users] CGIWRAP and Nagios
>=20
> Hi Nathan!
>=20
> First I tried without multi-user script directory, but my=20
> scenario did=20
> not work. So I just tried it, but nothoing has changed.
>=20
> The problem in this case, - I think - that cgiwrap assumes that user=20
> scripts are in /home/public_html/cgi-bin directory. It is true almost=20
> every normal multi user web server. However Nagios scripts are=20
> /usr/local/nagios/sbin and apache cofig file contains a " ScripAlias=20
> /nagios/cgi-bin /usr/local/nagios/sbin " raw. And this computer runs=20
> Apache only for Nagios web interface.
>=20
>  From the " Extracted PATH_INFO '/cgi-bin/grouplist.cgi' ".=20
> is not correct
>=20
> There is a .htaccess file in /usr/local/nagios/sbin directory, but I=20
> can't understand the relevant documentation (auth-cgi-bin directory).
>=20
> Sorry for my English.  I can guess, that I missed some minor=20
> thing, but=20
> I couldn't find it. Please send me some hints.
>=20
> And thank you for the cgiwrap. I read though some suexec=20
> document but it=20
> seems to more comlicated than cgoiwrap.
>=20
> Bye, Tamas.
>=20
> Neulinger, Nathan wrote:
>=20
> >Why do you have a multi-user script directory configured? That should
> >only be used in VERY specialized circumstances...=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 Horvath Tamas
> >>Sent: Wednesday, August 18, 2004 12:29 PM
> >>To: cgi...@li...
> >>Subject: [cgiwrap-users] CGIWRAP and Nagios
> >>
> >>Hi List!
> >>
> >>I use Nagios 1.2 + Apache 2.0.49 with mod_ssl 2.0.49 and=20
> >>OpenSSL 0.9.7d=20
> >>on Debian Woody 3.1. Now I can access Nagios via HTTPS and=20
> installed=20
> >>cgiwrap 3.9. For the main Apache directrory it works, but for=20
> >>nagios it=20
> >>doesn't.
> >>
> >>I always get this:"
> >>Script Base Directory:  '/home/nagios/public_html/cgi-bin'
> >>MultiUser Script Base Directory:  '/nagios/cgi-bin/'
> >>    Fetching script string
> >>
> >>Trying to extract script from PATH_INFO
> >>Extracted PATH_INFO '/cgi-bin/grouplist.cgi'
> >>
> >>*****************
> >>* CGIWrap Error *
> >>*****************
> >>
> >>Script File Not Found!
> >>"
> >>I made /home/nagios/public_html/cgi-bin symlink to=20
> >>/usr/local/nagios/sbin, but it doesn't work.
> >>If somebody managed to install cgiwrap with nagios, please help me.
> >>
> >>Any help would be appreciated. Thanks very very much.
> >>
> >>Tamas.
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is sponsored by Shop4tech.com-Lowest price on=20
> Blank Media
> >>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> >>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> >>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> >>_______________________________________________
> >>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 Nagios

[Horvath T. <zs...@ax...>]

Hi Nathan!

First I tried without multi-user script directory, but my scenario did 
not work. So I just tried it, but nothoing has changed.

The problem in this case, - I think - that cgiwrap assumes that user 
scripts are in /home/public_html/cgi-bin directory. It is true almost 
every normal multi user web server. However Nagios scripts are 
/usr/local/nagios/sbin and apache cofig file contains a " ScripAlias 
/nagios/cgi-bin /usr/local/nagios/sbin " raw. And this computer runs 
Apache only for Nagios web interface.

 From the " Extracted PATH_INFO '/cgi-bin/grouplist.cgi' ". is not correct

There is a .htaccess file in /usr/local/nagios/sbin directory, but I 
can't understand the relevant documentation (auth-cgi-bin directory).

Sorry for my English.  I can guess, that I missed some minor thing, but 
I couldn't find it. Please send me some hints.

And thank you for the cgiwrap. I read though some suexec document but it 
seems to more comlicated than cgoiwrap.

Bye, Tamas.

Neulinger, Nathan wrote:

>Why do you have a multi-user script directory configured? That should
>only be used in VERY specialized circumstances... 
>
>------------------------------------------------------------
>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 Horvath Tamas
>>Sent: Wednesday, August 18, 2004 12:29 PM
>>To: cgi...@li...
>>Subject: [cgiwrap-users] CGIWRAP and Nagios
>>
>>Hi List!
>>
>>I use Nagios 1.2 + Apache 2.0.49 with mod_ssl 2.0.49 and 
>>OpenSSL 0.9.7d 
>>on Debian Woody 3.1. Now I can access Nagios via HTTPS and installed 
>>cgiwrap 3.9. For the main Apache directrory it works, but for 
>>nagios it 
>>doesn't.
>>
>>I always get this:"
>>Script Base Directory:  '/home/nagios/public_html/cgi-bin'
>>MultiUser Script Base Directory:  '/nagios/cgi-bin/'
>>    Fetching script string
>>
>>Trying to extract script from PATH_INFO
>>Extracted PATH_INFO '/cgi-bin/grouplist.cgi'
>>
>>*****************
>>* CGIWrap Error *
>>*****************
>>
>>Script File Not Found!
>>"
>>I made /home/nagios/public_html/cgi-bin symlink to 
>>/usr/local/nagios/sbin, but it doesn't work.
>>If somebody managed to install cgiwrap with nagios, please help me.
>>
>>Any help would be appreciated. Thanks very very much.
>>
>>Tamas.
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>>_______________________________________________
>>cgiwrap-users mailing list
>>cgi...@li...
>>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>>
>>
>>
>>    
>>
>
>
>  
>

RE: [cgiwrap-users] CGIWRAP and Nagios

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

Why do you have a multi-user script directory configured? That should
only be used in VERY specialized circumstances...=20

------------------------------------------------------------
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 Horvath Tamas
> Sent: Wednesday, August 18, 2004 12:29 PM
> To: cgi...@li...
> Subject: [cgiwrap-users] CGIWRAP and Nagios
>=20
> Hi List!
>=20
> I use Nagios 1.2 + Apache 2.0.49 with mod_ssl 2.0.49 and=20
> OpenSSL 0.9.7d=20
> on Debian Woody 3.1. Now I can access Nagios via HTTPS and installed=20
> cgiwrap 3.9. For the main Apache directrory it works, but for=20
> nagios it=20
> doesn't.
>=20
> I always get this:"
> Script Base Directory:  '/home/nagios/public_html/cgi-bin'
> MultiUser Script Base Directory:  '/nagios/cgi-bin/'
>     Fetching script string
>=20
> Trying to extract script from PATH_INFO
> Extracted PATH_INFO '/cgi-bin/grouplist.cgi'
>=20
> *****************
> * CGIWrap Error *
> *****************
>=20
> Script File Not Found!
> "
> I made /home/nagios/public_html/cgi-bin symlink to=20
> /usr/local/nagios/sbin, but it doesn't work.
> If somebody managed to install cgiwrap with nagios, please help me.
>=20
> Any help would be appreciated. Thanks very very much.
>=20
> Tamas.
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20
>=20
>=20

[cgiwrap-users] CGIWRAP and Nagios

[Horvath T. <zs...@ax...>]

Hi List!

I use Nagios 1.2 + Apache 2.0.49 with mod_ssl 2.0.49 and OpenSSL 0.9.7d 
on Debian Woody 3.1. Now I can access Nagios via HTTPS and installed 
cgiwrap 3.9. For the main Apache directrory it works, but for nagios it 
doesn't.

I always get this:"
Script Base Directory:  '/home/nagios/public_html/cgi-bin'
MultiUser Script Base Directory:  '/nagios/cgi-bin/'
    Fetching script string

Trying to extract script from PATH_INFO
Extracted PATH_INFO '/cgi-bin/grouplist.cgi'

*****************
* CGIWrap Error *
*****************

Script File Not Found!
"
I made /home/nagios/public_html/cgi-bin symlink to 
/usr/local/nagios/sbin, but it doesn't work.
If somebody managed to install cgiwrap with nagios, please help me.

Any help would be appreciated. Thanks very very much.

Tamas.

[cgiwrap-users] php-cgiwrap vs. suPHP? cgiwrap vs. suEXEC?

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

I'm a beginner when it comes to setting up a secure environment for 
users to run scripts. I've got suEXEC working - now I'm trying to run 
PHPs as users' ids (without requiring a shebang in each script). I've 
looked around and read the sparse documentation I could find. I still 
need to know:

1) What advantage does cgiwrap present over suEXEC?

2) Should I use php-cgiwrap, or suPHP for PHPs?

If you have some references I missed with information on these topics, 
please let me know! I tried the cgiwrap docs, this list's archives, and 
google.

Any help gratefully appreciated!

Jack