cgiwrap-users

Re: [cgiwrap-users] ENV - Variables

[Joe S. <joe...@am...>]

Greetings Jerome,

If you mean to find out what they and their values are, then
try this perl script:

#!/usr/local/bin/perl

foreach $ind (keys %ENV) {
        print "$ind ==> $ENV{$ind}\n" ;
}

But I'm a newbie with cgiwrap, so not sure if there's something in
there that'll simulate the above...

HTH,
-- 
----->  Joe...@am...   M/S 521  Phone: USA(512)602-4514
----->  5204 E. Ben White Blvd., Austin, TX 78741
----->  AlphaPager: USA(512)622-0251 or 512...@pa...
The modern adversarial court method is concerned, not with essential 
truth, only with outcome.
------
"Jerome A. Simon" wrote:
> 
> Hello
> 
> Does anyone know how to get all the 'ENV' variables
> back?
> 
> I am trying to make a 'hit tracker' but the 'REFERER'
> value only contains the script address itself.
> 
> (P.S. - if this got sent twice... sorry! I sent out my
> first message before getting my 'confirmation' back -
> so I figured I needed to send it again?)
> --
> 
>   JaS Software
>   P.O. Box 361
>   Sweet Home, Oregon, USA
>   97386
> 
>   http://www.jassoftware.com
>   mailto:ja...@ja...
>  = - = - = - = - = - = - = - = - = - = - = - = - = - =
> - = -
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

[cgiwrap-users] POST Method Problems

[Liam R. <ja...@ui...>]

Hi folks,

I've seen several posts on this, but no solutions.  The problem is that 
POSTed variables never make it through cgiwrap to the called script using 
the AddHandler directive.  Does anyone know what is going on with 
this?  I've been reading the list archive all afternoon without any luck, 
but maybe I missed it?

Thanks in advance for any input,

--Liam


Liam Reimers, Senior Systems Programmer
ULTIMATE Internet Access, Inc.
(909) 482-1634  (800) 982-6898
http://www.uia.net

[cgiwrap-users] ENV - Variables

[Jerome A. S. <ja...@ja...>]

Hello

Does anyone know how to get all the 'ENV' variables
back?

I am trying to make a 'hit tracker' but the 'REFERER'
value only contains the script address itself.

(P.S. - if this got sent twice... sorry! I sent out my
first message before getting my 'confirmation' back -
so I figured I needed to send it again?)
--

  JaS Software
  P.O. Box 361
  Sweet Home, Oregon, USA
  97386

  http://www.jassoftware.com
  mailto:ja...@ja...
 = - = - = - = - = - = - = - = - = - = - = - = - = - =
- = -

RE: [cgiwrap-users] Version differences

[John G. <jgi...@li...>]

On Mon, 8 Apr 2002, Neulinger, Nathan wrote:

>Ah, yeah, PATH_TRANSLATED, I thought you said you had a problem
>executing the script? The path_translated stuff might cause a problem
>within your code. I don't remember all the permutations unfortunately.
>I'm pretty sure that the more recent behavior is more correct according
>to the CGI specs, but I never use PATH_TRANSLATED.

Ah right, thanks for the help, we've found a workaround to the problem,
involving symlinks.

	John

RE: [cgiwrap-users] Version differences

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

Ah, yeah, PATH_TRANSLATED, I thought you said you had a problem
executing the script? The path_translated stuff might cause a problem
within your code. I don't remember all the permutations unfortunately.
I'm pretty sure that the more recent behavior is more correct according
to the CGI specs, but I never use PATH_TRANSLATED.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: John Gilbertson [mailto:jgi...@li...]=20
> Sent: Monday, April 08, 2002 8:30 AM
> To: Neulinger, Nathan
> Cc: cgi...@li...
> Subject: Re: [cgiwrap-users] Version differences
>=20
>=20
> On Mon, 8 Apr 2002, Nathan Neulinger wrote:
>=20
> >Nothing should have changed that would cause that. I would suggest
> >double checking permissions on the path up to the script. It=20
> sounds like
> >it isn't successfully locating the script.
>=20
> All of the permissions are correct across both versions.
>=20
> >Also, you might include the cgiwrapd output and look it over=20
> for how it
> >decoded the path to the script. I tried running the URL's,=20
> but it gave
> >the access control error.
>=20
> The differences between the two versions whch looks like it causes the
> problem is in the PATH_TRANSLATED variabel just before runing the CGI:
>=20
> Working:
> Environment Variables:
>      QUERY_STRING: ''
>       SCRIPT_NAME: '/cgi-bin/cgiwrapd/sbyrne/htmSQL'
>         PATH_INFO: '/www/sbyrne/sasweb/packageusage.hsql'
>   PATH_TRANSLATED:
> '/usr/local/etc/httpd/htdocs/www/sbyrne/sasweb/packageusage.hsql'
>=20
> Non working:
> Environment Variables:
>      QUERY_STRING: ''
>       SCRIPT_NAME: '/cgi-bin/cgiwrapd/sbyrne/htmSQL'
>   SCRIPT_FILENAME: '/home/qcl/sbyrne/cgi-bin/htmSQL'
>         PATH_INFO: '/www/sbyrne/sasweb/packageusage.hsql'
>   PATH_TRANSLATED:
> '/home/qcl/sbyrne/cgi-bin/www/sbyrne/sasweb/packageusage.hsql'
>=20
> The second seems to assume a different prefix for the=20
> PATH_INFO than the
> first.
>=20
> I've attached copies of both cgiwrapd outputs.
>=20
> Thanks
> 	John
>=20

Re: [cgiwrap-users] Version differences

[John G. <jgi...@li...>]

On Mon, 8 Apr 2002, Nathan Neulinger wrote:

>Nothing should have changed that would cause that. I would suggest
>double checking permissions on the path up to the script. It sounds like
>it isn't successfully locating the script.

All of the permissions are correct across both versions.

>Also, you might include the cgiwrapd output and look it over for how it
>decoded the path to the script. I tried running the URL's, but it gave
>the access control error.

The differences between the two versions whch looks like it causes the
problem is in the PATH_TRANSLATED variabel just before runing the CGI:

Working:
Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/cgi-bin/cgiwrapd/sbyrne/htmSQL'
        PATH_INFO: '/www/sbyrne/sasweb/packageusage.hsql'
  PATH_TRANSLATED:
'/usr/local/etc/httpd/htdocs/www/sbyrne/sasweb/packageusage.hsql'

Non working:
Environment Variables:
     QUERY_STRING: ''
      SCRIPT_NAME: '/cgi-bin/cgiwrapd/sbyrne/htmSQL'
  SCRIPT_FILENAME: '/home/qcl/sbyrne/cgi-bin/htmSQL'
        PATH_INFO: '/www/sbyrne/sasweb/packageusage.hsql'
  PATH_TRANSLATED:
'/home/qcl/sbyrne/cgi-bin/www/sbyrne/sasweb/packageusage.hsql'

The second seems to assume a different prefix for the PATH_INFO than the
first.

I've attached copies of both cgiwrapd outputs.

Thanks
	John

Re: [cgiwrap-users] Version differences

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

Nothing should have changed that would cause that. I would suggest
double checking permissions on the path up to the script. It sounds like
it isn't successfully locating the script.

Also, you might include the cgiwrapd output and look it over for how it
decoded the path to the script. I tried running the URL's, but it gave
the access control error.

Also, the problem most likely isn't with the /www part. It's with
locating htmSQL. 

-- Nathan

John Gilbertson wrote:
> 
> We have 2 machines running slightly different versions of CGIWrap, and
> in most respects they're running perfectly fine, apart from one user who
> has found their CGI's no longer work on our development server, which is
> running a newer version of CGIWrap.
> 
> Here's the setup:
> csdinfo3 - CGIWrap 3.6.4
> csdinfo4 - CGIwrap 3.7.1
> 
> Working script:
> http://csdinfo3.liv.ac.uk/cgi-bin/cgiwrapd/sbyrne/htmSQL/www/sbyrne/sasweb/packageusage.hsql
> (as in script actualyl runs)
> 
> Broken script:
> http://csdinfo4.liv.ac.uk/cgi-bin/cgiwrapd/sbyrne/htmSQL/www/sbyrne/sasweb/packageusage.hsql
> 
> It appears that 3.7.1 is behaving differently in translating the URL.
> 
> The file /www/sbyrne/sasweb/packageusage.hsql exists from both servers
> (remote mount), yet only the 3.6.4 version seems able to understand that
> it is an argument to the htmSQL cgi (AFAICT)
> 
> Both versions of CGI wrap were compiled with exactly the same set of
> configure options. (listed at bottom)
> 
> Is there some new option to 3.7.1 which we need to turn on/off to get
> this to work, or any other pointers to what might be going wrong?
> 
> --
>         John Gilbertson
> 
> configure settings:
> ./configure \
> --prefix=/usr/local/etc/httpd/Port80 \
> --with-perl=/apps5/pdtools/gnu/bin/perl5 \
> --with-local-contact-name=webmaster \
> --with-local-contact-email=web...@li... \
> --with-install-group=other \
> --with-install-dir=/usr/local/etc/httpd/Port80/cgi-bin \
> --with-cgi-dir=cgi-bin \
> --with-httpd-user=nobody \
> --with-minimum-uid=1024 \
> --with-logging-file=/usr/local/etc/httpd/Port80/logs/cgiwrap.log \
> --with-script-subdirs \
> --with-rlimit-cpu=30 \
> --with-rlimit-vmem=15000000 \
> --with-rlimit-as=15000000 \
> --with-rlimit-fsize=15000000 \
> --with-rlimit-data=15000000 \
> --with-rlimit-stack=15000000 \
> --with-rlimit-core=15000000 \
> --with-rlimit-rss=15000000 \
> --with-rlimit-nproc=16 \
> --with-rlimit-nofile=64 \
> --with-allow-file=/usr/local/etc/httpd/Port80/conf/cgiwrap.allow \
> --with-deny-file=/usr/local/etc/httpd/Port80/conf/cgiwrap.deny \
> --with-host-checking
> 
> _______________________________________________
> 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
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] Version differences

[John G. <jgi...@li...>]

We have 2 machines running slightly different versions of CGIWrap, and
in most respects they're running perfectly fine, apart from one user who
has found their CGI's no longer work on our development server, which is
running a newer version of CGIWrap.

Here's the setup:
csdinfo3 - CGIWrap 3.6.4
csdinfo4 - CGIwrap 3.7.1

Working script:
http://csdinfo3.liv.ac.uk/cgi-bin/cgiwrapd/sbyrne/htmSQL/www/sbyrne/sasweb/packageusage.hsql
(as in script actualyl runs)

Broken script:
http://csdinfo4.liv.ac.uk/cgi-bin/cgiwrapd/sbyrne/htmSQL/www/sbyrne/sasweb/packageusage.hsql

It appears that 3.7.1 is behaving differently in translating the URL.

The file /www/sbyrne/sasweb/packageusage.hsql exists from both servers
(remote mount), yet only the 3.6.4 version seems able to understand that
it is an argument to the htmSQL cgi (AFAICT)

Both versions of CGI wrap were compiled with exactly the same set of
configure options. (listed at bottom)

Is there some new option to 3.7.1 which we need to turn on/off to get
this to work, or any other pointers to what might be going wrong?

-- 
	John Gilbertson

configure settings:
./configure \
--prefix=/usr/local/etc/httpd/Port80 \
--with-perl=/apps5/pdtools/gnu/bin/perl5 \
--with-local-contact-name=webmaster \
--with-local-contact-email=web...@li... \
--with-install-group=other \
--with-install-dir=/usr/local/etc/httpd/Port80/cgi-bin \
--with-cgi-dir=cgi-bin \
--with-httpd-user=nobody \
--with-minimum-uid=1024 \
--with-logging-file=/usr/local/etc/httpd/Port80/logs/cgiwrap.log \
--with-script-subdirs \
--with-rlimit-cpu=30 \
--with-rlimit-vmem=15000000 \
--with-rlimit-as=15000000 \
--with-rlimit-fsize=15000000 \
--with-rlimit-data=15000000 \
--with-rlimit-stack=15000000 \
--with-rlimit-core=15000000 \
--with-rlimit-rss=15000000 \
--with-rlimit-nproc=16 \
--with-rlimit-nofile=64 \
--with-allow-file=/usr/local/etc/httpd/Port80/conf/cgiwrap.allow \
--with-deny-file=/usr/local/etc/httpd/Port80/conf/cgiwrap.deny \
--with-host-checking

Re[2]: [cgiwrap-users] UID from file

[Daniel L. <da...@lo...>]

Hi,

> Piotr Klaban:
> I agree that this is safer to check the owner of the script
> ... sometimes I copied cgi/php scripts between different directories
> as root (then with root or source script permissions).

I figured out that the '-p' switch for 'cp' is quite recommendable
when working as root :)

Daniel

Re: [cgiwrap-users] UID from file

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

On Thu, Mar 28, 2002 at 07:10:44AM -0600, Nathan Neulinger wrote:
> Daniel Lorch wrote:
> > In particular it's the way how cgiwrap extracts the username under
> > which the script will be executed. A friend just told me he had
> > patched cgiwrap to extract the username from the file owner.
> > 
> > So, what's exactly wrong with this? A user cannot chown a file to
> > another user and configuration would be extremely faciliated.
> 
> Many platforms do allow giveaway chown. 

A while ago Daniel pointed me to the page
http://steven.haryan.to/mod_cgiwrap/mod_cgiwrap.html
where is a patch for cgiwrap (mod_cgiwrap) that
includes --with-docroot-mode and --with-docroot-owner
options. At the above page there is also short patch for
empty PATH_INFO env. variable. You may consider looking
at this patch in the free time. I do not know if it is
necessary, but there are problems with this env. variable
under php (though I cann't describe it deeper now).

Below is the description of the mentioned options
extracted from the patch:

+Added --with-docroot-mode configure option.
+
+Added --with-docroot-owner configure option.
+
+If docroot mode is active, instead of looking for a cgi dir under user's
+home directory, cgiwrap will instead look at the DOCUMENT_ROOT variable and
+make that the cgi base directory.
+
+If docroot owner is active, instead of honoring the /username/ part of
+PATH_INFO, cgiwrap will instead use the ownership settings of the document
+root. You can put any string in the /username/ part in PATH_INFO since it
+will be ignored.
+
+Both these options are suitable for virtual hosting (well, at least make it
+more convenient on the configuration side).

This is not what Daniel want - it extracts user from the
directory, not the script itself. That behaviour could help
creating virtual server directories outside of the user home dir,
or create several virtual server configurations under the same
user home directory. [...] if the new apache 2.0 would have
working perchild MPM, then cgiwrap would be unnecessary
for virtual hosts... but it is in beta stage for now.

> > But it *must* be something wrong with it, otherwise cgiwrap would
> > work like this by default, right? Is it more error-prone?
> 
> It's a multi-level protection. First, files have to be in particular
> user's dir, and they have to be owned by that user, and they have to
> have appropriate permissions, etc. 

I agree that this is safer to check the owner of the script
... sometimes I copied cgi/php scripts between different directories
as root (then with root or source script permissions).

Regards,

-- 
Piotr Klaban

[cgiwrap-users] CGIWrap Error: Script dir not found

[Brian L. <Bri...@su...>]

CGIWrap users,

I've been using an old version of CGI Wrap on an old Linux box with Apache
for 5 years. Recently this box bit the dust and I've built a new box with
Apache 1.3.24 and CGI Wrap 3.7.1. I've compiled the CGIWrap on Linux with
GCC using the -with-httpd-user=nobody option since my Apache server is
running as user:nobody, group:nobody (the default configuration).

I'm running a number of websites on Apache using the name-based virtual host
method. In my <Virtualhost> directive I've specified the following (this is
how my old server was configured):

ScriptAlias /cgi-bin/ /www/domainname.com/cgi-bin/cgiwrap/nobody/

When I try to run the printenv CGI script included with Apache in the
/www/domainname.com/cgi-bin directory, I get the error, "CGIWrap Error:
Script dir not found".

The /www/domainname.com/cgi-bin directory is owner and group "nobody" with
the drwxr-xr-x permissions.

Is this enough information for someone to be able to tell me why I am
receiving this error?

Brian Lawrence
IT/IS Manager
Sufficient Systems, Inc.
Direct: (612) 436-7152
Office: (612) 379-8168
Cell: (612) 280-1067
Fax: (612) 379-8132 
E-Mail: bri...@su...

Re: [cgiwrap-users] UID from file

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

Daniel Lorch wrote:
> 
> Hi,
> 
> after looking through the cgiwrap sources I got curious why
> certain decisions were made.
> 
> In particular it's the way how cgiwrap extracts the username under
> which the script will be executed. A friend just told me he had
> patched cgiwrap to extract the username from the file owner.
> 
> So, what's exactly wrong with this? A user cannot chown a file to
> another user and configuration would be extremely faciliated.

Many platforms do allow giveaway chown. 

> But it *must* be something wrong with it, otherwise cgiwrap would
> work like this by default, right? Is it more error-prone?

It's a multi-level protection. First, files have to be in particular
user's dir, and they have to be owned by that user, and they have to
have appropriate permissions, etc. 

> Thanks for your help.
> 
> Daniel
> 
> _______________________________________________
> 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
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] UID from file

[Daniel L. <da...@lo...>]

Hi,

after looking through the cgiwrap sources I got curious why
certain decisions were made.

In particular it's the way how cgiwrap extracts the username under
which the script will be executed. A friend just told me he had
patched cgiwrap to extract the username from the file owner.

So, what's exactly wrong with this? A user cannot chown a file to
another user and configuration would be extremely faciliated.

But it *must* be something wrong with it, otherwise cgiwrap would
work like this by default, right? Is it more error-prone?

Thanks for your help.

Daniel

[cgiwrap-users] cgiwrap with iPlanet webserver ACL's

[Ruud v. M. <Ruu...@as...>]

hi,

has anybody succesfully implemented iPlanet webserver ACL's for specific
user cgi-bin directories, disabling the cgiwrap functionality for a
certain group?

e.g. http://www.server.com/cgiwrap/username/scriptname is restricted for
a specific group of users. 

Both acl-types path and uri don't seem to work?

acl "uri=/cgi-bin/cgiwrap/account/nonconf/";
deny (all)
 (user = "anyone");

allow (read,execute)
 (user = "all");

acl "uri=/cgi-bin/cgiwrap/account/secret/";
deny (all)
 (user = "anyone");

allow (read,execute)
 (user = "username");

acl "path=/home/account/cgi-bin/";
deny (all)
 (user = "anyone");

allow (read,execute)
 (user = "all");

deny (all)
 (group = "public");



Only the specific acl to the existing cgiwrap directory can be
restricted.

acl "path=/usr/netscape/cgiwrap/";
deny (all)
 (user = "anyone");

allow (read,write,execute)
 (user = "all");

deny (all)
 (group = "public");


Anybody has gotten experience with this?

Thanks for your response.

-- 
Kind regards,

Ruud van Meer

Re: [cgiwrap-users] SetUID

[Ralph H. <rj...@mo...>]

> I'm using a cobalt Raq3 and I'm getting the following error while using one
> of a client's scripts.  Can someone help me with this?
>
> "The cgiwrap executable(s) were not made setuid-root. This is required for
> it to function properly. (SetUID root is needed in order to change the uid
> to that of the script owner. This is an installation error please make the
> executable setuid root, or use the 'make install' method of installing the
> executables."

It means the cgiwrap executables must have these permissions:

-rwsr-xr-x  4 root  wheel  65544 Nov  6 13:20 cgiwrap
   ^
   ^---setuid must be set for owner and owner must be root

[cgiwrap-users] SetUID

[dlyles <dl...@un...>]

I'm using a cobalt Raq3 and I'm getting the following error while using one
of a client's scripts.  Can someone help me with this?

"The cgiwrap executable(s) were not made setuid-root. This is required for
it to function properly. (SetUID root is needed in order to change the uid
to that of the script owner. This is an installation error please make the
executable setuid root, or use the 'make install' method of installing the
executables."

[cgiwrap-users] CGIWrap - Installation Issues

[shimi <sh...@fr...>]

Hello List,

I am writing to you after digging in the mailing list archive, google, 
and god knows what with no luck of finding the same sympthom I have.

First, I installed it normally:
./configure 
--with-httpd-user=apache 
--with-report-rusage 
--with-logging-file=/var/log/httpd/cgiwrap.log 
--with-install-dir=/usr/cgiwrap 
--with-perl=/usr/bin/perl 
--with-install-group=apache 

Installation goes fine.

Running the program works.

Now, I added in httpd.conf:
AddHandler cgi-wrapper .cgi
Action cgi-wrapper /usr/cgiwrap/cgiwrap

(I copied that setup from a Cobalt RaQ3 box I own)

This caused all calls to cgi scripts to return:
404 error: /usr/cgiwrap/cgiwrap/index.cgi does not exist. (remember, the 
request was for /, or, /index.cgi...)

I have Apache 1.3.22 on RedHat Linux 7.2. Configuration came from RedHat, 
and the only modification I added was a vhost:

<Directory "/home/sites/domain/www/">
    AllowOverride None
    Options Indexes
    Order allow,deny
    Allow from all
</Directory>
<VirtualHost *>
    ServerAdmin webmaster@domain
    DocumentRoot /home/sites/domain/www/
    ServerName www.domain
    ServerAlias domain
    ErrorLog /home/sites/domain/logs/error.log
    CustomLog /home/sites/domain/logs/web.log common
    AddHandler cgi-wrapper .cgi
    AddHandler cgi-wrapper .pl
    AddHandler server-parsed .shtml
    AddType    text/html     .shtml
</VirtualHost>

This resulted in what I said earlier.

Looking in the error log found out that /usr/... is relevant to 
DocumentRoot from some reason.

To bypass that behaviour I did the following:

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

That worked, and CGIWrap is now launched.

The problem is that it, from some reason, trying to find the owner of the 
file after the name of the file, instead of the owner.

I.e. "Cannot find username 'index.cgi' in system's password file" (as if 
the user does not exist)

Can you please help?

Thanks.

p.s. any other solution to run cgi's (and perhaps phps?) as the owner of 
them would be just fine for me, if you know one...

- shimi.

RE: [cgiwrap-users] my rewrite rule...

[Jeff B. M. <jef...@qw...>]

To be a little more descriptive the problem I have is that the ENV variable
"SCRIPT_NAME" ends up being:

/cgi-bin/cgiwrap/USERNAME/script.cgi

and yet the "SCRIPT_URL" is:

/cgi-bin/script.cgi

I can solve this in all scripts by looking for the place where they are
looking at SCRIPT_NAME and pointing that to the SCRIPT_URL
but would rather fix my rewrite rule to be more script friendly.

any ideas?

thanks,

Jeff

> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...]On Behalf Of Jeff Bert
> MTIA
> Sent: Wednesday, February 20, 2002 10:24 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] my rewrite rule...
>
>
> I'm pretty new to this stuff and am having a little trouble with rewrite
> rules... the ones that are suggested in the tips and tricks don't seem to
> work for my virtual hosts.  All the vhosts have domain names like
> "myhost.ods.org" (ods.org is an open domain server) and so the
> rewrite rule
> I've gotten to work is:
>
> <VirtualHost>
> ...
> ServerAlias /cgi-bin/ /var/www/cgi-bin/
> RewriteRule ^/cgi-bin/(.*) /cgi-bin/cgiwrap/USERNAME/$1 [PT]
> ...
> </VirtualHost>
>
> I've run into a couple of scripts that choke on this rewrite rule but most
> like it.  Is there a more elegant way to do this?
>
> thanks,
>
> Jeff
>
>
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>

[cgiwrap-users] my rewrite rule...

[Jeff B. M. <jef...@qw...>]

I'm pretty new to this stuff and am having a little trouble with rewrite
rules... the ones that are suggested in the tips and tricks don't seem to
work for my virtual hosts.  All the vhosts have domain names like
"myhost.ods.org" (ods.org is an open domain server) and so the rewrite rule
I've gotten to work is:

<VirtualHost>
...
ServerAlias /cgi-bin/ /var/www/cgi-bin/
RewriteRule ^/cgi-bin/(.*) /cgi-bin/cgiwrap/USERNAME/$1 [PT]
...
</VirtualHost>

I've run into a couple of scripts that choke on this rewrite rule but most
like it.  Is there a more elegant way to do this?

thanks,

Jeff

RE: [cgiwrap-users] vhosts + mod_throttle + cgiwrap

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

You'd probably need to do per-domain cgiwrap installs/configs, with
users.allow.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Kasper (Swebase AB) [mailto:ka...@sw...]=20
> Sent: Tuesday, February 19, 2002 10:37 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] vhosts + mod_throttle + cgiwrap
>=20
>=20
>  user1=20
> =20
>  userid olle=20
>  domain olle.nu=20
> =20
>  user2=20
> =20
>  userid bolle=20
>  domain bolle.nu=20
> =20
 http://olle.nu/cgi-bin/cgiwrap/olle/script.pl=20
=20
 then mod_throttle counts on olle.nu BUT when i change the domainname to
the other domain on the server but the same cgi script like=20
=20
 http://bolle.nu/cgi-bin/cgiwrap/olle/script.pl=20
=20
  mod_throttle do not count on the script users domain (offcourse since
the domainname is not the same) it counts on another domain on the same
server.=20
=20
 ..... NOT GOOD.=20
=20
 Is there any way to do so that cgiwrap can not go arround mod_throttle
?=20
=20
 Regards=20
 Kasper (sweden)=20
              =20

_______________________________________________
cgiwrap-users mailing list
cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

[cgiwrap-users] vhosts + mod_throttle + cgiwrap

[Kasper (S. AB) <ka...@sw...>]

 user1 
 
 userid olle 
 domain olle.nu 
 
 user2 
 
 userid bolle 
 domain bolle.nu 
 
 http://olle.nu/cgi-bin/cgiwrap/olle/script.pl 
 
 then mod_throttle counts on olle.nu BUT when i change the domainname to the other domain on the server but the same cgi script like 
 
 http://bolle.nu/cgi-bin/cgiwrap/olle/script.pl 
 
  mod_throttle do not count on the script users domain (offcourse since the domainname is not the same) it counts on another domain on the same server. 
 
 ..... NOT GOOD. 
 
 Is there any way to do so that cgiwrap can not go arround mod_throttle ? 
 
 Regards 
 Kasper (sweden) 
               

Re: [cgiwrap-users] php-cgiwrap and RPM install

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

On Fri, Feb 15, 2002 at 02:18:49PM -0800, Jeff Bert MTIA wrote:
> use PHP-CGIWRAP.  So I took the RPM source for PHP and in the spec file

What is this PHP-CGIWRAP? Is that any package or just
set of configuration lines?

> #rpm -Uvh php-4.0.6......src.rpm
> *** here I went to the .spec file and added "--enable-discard-path" to the
> configure options.
> #rpm -bb php-4.0.6......src.rpm
> #rpm -ivh php-4.0.6......src.rpm

Where do you install php binary version? "rpm -ivh php-4.0.6......src.rpm"
would install just a sources again. Install the file with 'i386.rpm'
at the end.

> Maybe this is more of a PHP problem but I wanted to know if anyone has
> successfully installed php-cgiwrap via an RPM install and if they did
> anything more than I did...

Yes, this is not a cgiwrap related, unless you run somewhere cgiwrap.
From your mail I understand that you can not run php as a simple cgi script.

Try execute any php script from the command line first:
  php -f script.php

If successful, then copy it to script.cgi (or copy it to cgi-bin/ directory etc.)
with the first line containing the php path:
  echo '#!/usr/bin/php' > script.cgi
  cat script.php >> script.cgi

Try execute it via the web server.
If you can see the php output in your browser, THEN
you can add cgiwrap to the apache configuration.

Regards,

-- 
Piotr Klaban

[cgiwrap-users] php-cgiwrap and RPM install

[Jeff B. M. <jef...@qw...>]

I had installed PHP and mod_php via an RPM.  I unistalled them so I could
use PHP-CGIWRAP.  So I took the RPM source for PHP and in the spec file
added "--enable-discard-path" and then rebuilt the RPM and installed it.
However, I now get a segmentation fault when I try to run php.  I really
want to get this going so I can wrap PHP.

Here's what I did:

#rpm -e mod_php
#rpm -e php
#rpm -Uvh php-4.0.6......src.rpm
*** here I went to the .spec file and added "--enable-discard-path" to the
configure options.
#rpm -bb php-4.0.6......src.rpm
#rpm -ivh php-4.0.6......src.rpm

Maybe this is more of a PHP problem but I wanted to know if anyone has
successfully installed php-cgiwrap via an RPM install and if they did
anything more than I did...

thanks,

jeff

[cgiwrap-users] Insecure installations of cgi wrappers (RTFM people!)

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

This isn't really a reporting of a vulnerability, it's more a reporting
of mind-bogglingly foolish administrators that refuse to follow
installation instructions and read the documentation.

(I've cc'd this to both the cgiwrap and apache development mailing
lists, but I'm sure certain it's not news to readers of either.)

Note the following from cgiwrap documentation:

---
   *VERY IMPORTANT* - Do NOT allow any non-trusted user to run scripts
          directly out of the main cgi-bin directory, as this will allow
          them to use cgiwrap to run any of the other users scripts. The
          reason for this is that if they can run scripts as the same
          userid as the web server, they can subvert some of cgiwrap's
          security checks to allow them to run other users scripts. I
          recommend not running ANY scripts on the web server directly,
          once you have cgiwrap installed.
---

I FREQUENTLY receive messages like this:

---
Hi :

My web host provides us with CgiWrap access.

However they only treat scripts installed inside cgi-bin to run as user
me and not nobody.

I wanted to know if there is a way to get CgiWrap to get
scripts installed outside cgi-bin to run as user me, and not
nobody ?
---

What that tell's me is that web host is a security disaster waiting to
happen because they are allowing both cgiwrap and scripts run directly
from cgi-bin. It won't necessarily give root or anything like that, but
it allows cgi scripts to have their environment COMPLETELY subverted. If
there are any scripts that rely upon the authentication or access
control provided by the web server (such as scripts to administer the
contents of databases), they can be subverted simply because all of that
information is passed via environment variables.

I hate to see cgiwrap or apache/suexec or any of the other wrappers get
the blame for administrators not reading the documentation.

About the only way I can think of getting around this problem would be
to have some sort of web-server -> cgi-wrapper token passing taking
place with a shared secret compiled into the wrapper executable,
combined with non-readable wrapper executables and web server config.
(And I haven't thought about it enough to be sure that wouldn't be
exploitable. With some of the ptrace stuff, I'd bet it probably could be
exploited pretty quick.) To my knowledge, none of the wrappers are
currently doing anything like this. CGIwrap most certainly isn't. 

-- Nathan
(Author of CGIwrap)

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] Insecure installations of cgi wrappers (RTFM people!)

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

This isn't really a reporting of a vulnerability, it's more a reporting
of mind-bogglingly foolish administrators that refuse to follow
installation instructions and read the documentation.

(I've cc'd this to both the cgiwrap and apache development mailing
lists, but I'm sure certain it's not news to readers of either.)

Note the following from cgiwrap documentation:

---
   *VERY IMPORTANT* - Do NOT allow any non-trusted user to run scripts
          directly out of the main cgi-bin directory, as this will allow
          them to use cgiwrap to run any of the other users scripts. The
          reason for this is that if they can run scripts as the same
          userid as the web server, they can subvert some of cgiwrap's
          security checks to allow them to run other users scripts. I
          recommend not running ANY scripts on the web server directly,
          once you have cgiwrap installed.
---

I FREQUENTLY receive messages like this:

---
Hi :

My web host provides us with CgiWrap access.

However they only treat scripts installed inside cgi-bin to run as user
me and not nobody.

I wanted to know if there is a way to get CgiWrap to get
scripts installed outside cgi-bin to run as user me, and not
nobody ?
---

What that tell's me is that web host is a security disaster waiting to
happen because they are allowing both cgiwrap and scripts run directly
from cgi-bin. It won't necessarily give root or anything like that, but
it allows cgi scripts to have their environment COMPLETELY subverted. If
there are any scripts that rely upon the authentication or access
control provided by the web server (such as scripts to administer the
contents of databases), they can be subverted simply because all of that
information is passed via environment variables.

I hate to see cgiwrap or apache/suexec or any of the other wrappers get
the blame for administrators not reading the documentation.

About the only way I can think of getting around this problem would be
to have some sort of web-server -> cgi-wrapper token passing taking
place with a shared secret compiled into the wrapper executable,
combined with non-readable wrapper executables and web server config.
(And I haven't thought about it enough to be sure that wouldn't be
exploitable. With some of the ptrace stuff, I'd bet it probably could be
exploited pretty quick.) To my knowledge, none of the wrappers are
currently doing anything like this. CGIwrap most certainly isn't. 

-- Nathan
(Author of CGIwrap)

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216