cgiwrap-users

[cgiwrap-users] RE: cgiwrap in a unusual environment.

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

CGIwrap is designed with user name used to look up the directory in the
password file. 

/cgi-bin/cgiwrap/userid/scriptname

should work fine, if 

/www/domain.com/cgi-bin/userid

is userid's home directory as far as the password file is concerned.

Now, for what is the path to cgi-bin-dir... you might try
--with-cgi-bin-dir="", but I'm not sure.

Might require code modifications though to get it to work right. 

-- Nathan

> -----Original Message-----
> From: universe [mailto:uni...@tr...]
> Sent: Tuesday, March 20, 2001 3:01 PM
> To: nn...@um...
> Subject: cgiwrap in a unusual environment.
> 
> 
> hi nathan,
> 
> i'll post this message directly to you, hopefully thats ok. 
> maybe you can take care of
> this when you find 5 free minutes...  thanks!
> 
> 
> 
> unfortunately i couldn't get cgiwrap to run under my environment.
> it looks like the following:
> 
> server cgi-bin root:
> /www/domain.com/cgi-bin
> 
> this is were cgiwrap is placed. accessible through
> http://www.domain.com/cgi-bin
> 
> server htdocs root:
> /www/domain.com/htdocs
> 
> there are about 100 users which have their home directory here:
> /www/domain.com/htdocs/user-directory
> 
> at the same time, this is their document root, so users can access
> their webspace through http://www.domain.com/user-directory
> 
> the goal is to provide the users the possibility to run cgi-scripts
> directly in their home directory (as they don't have access to
> anything else, which is good).
> 
> however, the username is different from the name of the users homedir!
> the username always has a leading "tm_" in it. e.g. if the homedir
> is "universe" (www.domain.com/universe) then the username on 
> the system
> is "tm_universe". this is the main problem as far as i can see since
> cgiwrap always trys to jump in a directory called "tm_universe", which
> of course doesn't exist.
> 
> we've tried the following:
> 
> compiling with "--cgi-bin-dir=.." in order to have cgiwrap jump
> out of the users homedir and immediately go back to it and execute
> the cgi. this was a attempt to avoid the username problem (username
> and user's home dir aren't equal, e.g. the username is "tm_metal"
> and the users homedir is:
> 
> /www/domain.com/htdocs/metal
> 
> cgiwrap jumps out of the users homedir just in order to jump back
> to it, which doesn't succeed since the username is different than
> the name of the homedir.
> 
> i could change the cgi-bin if that helps, but i don't see any
> relation to the problem there.
> 
> any suggestions?
> 
> 
> thanks,
> markus
> 
> 
> -- uni...@tr...
> 

[cgiwrap-users] chroot

[Tsukaeru.net <web...@ts...>]

I am trying to use -with-chroot option in the latest ver. of cgiwrap, but it
doesn't seem to be having any effect what so ever. Searching the source, I
can not find anywhere that would actually perform this kind of function.

If anyone can help with using the chroot option, it would be most
appreciated.

Regards,

Jason Frisch

[cgiwrap-users] RE: RaQ2

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

You shouldn't have to do anything. There is no runtime configuration of
cgiwrap other than yes/no exection by userid, and that isn't turn on in the
RaQs. All cgiwrap does is switch to the given uid/gid of the user (at least
in the standard version). The userid determination is done completely
differently on the Raq.

Why don't you do what I said so you can determine why it isn't able to
create the files/dirs.

> -----Original Message-----
> From: Ray Guthrie [mailto:ra...@we...]
> Sent: Tuesday, March 13, 2001 2:30 PM
> To: Neulinger, Nathan R.
> Subject: RE: RaQ2
> 
> 
> I know it's not a problem with your software.  I was just 
> wondering if you
> would know how to configure it since they were not able to 
> help me at all.
> 
> Does CGI Wrap allow CGI scripts to write and rename files?
> 
> If so, where do you keep your configuration file?  What is a 
> sample of text
> that is in it?
> 
> I have never heard of CGI Wrap until I got this server, so I 
> am a little
> lost.  Do you have, or know of some documentation that can 
> teach me about
> your software?
> 
> Thanks!
> Ray.
> 
> -----Original Message-----
> From: Neulinger, Nathan R. [mailto:nn...@um...]
> Sent: Tuesday, March 13, 2001 11:47 AM
> To: 'Ray Guthrie'
> Cc: 'cg...@un...'
> Subject: RE: RaQ2
> 
> 
> You need to see exactly where the script is running from (what is the
> current working directory when it runs) and exactly what 
> uid+gid+auxgroups
> it is running as, and what the permissions of the CWD are.
> 
> This is NOT a problem with my software, it's a problem with their
> customization of it and how they have it installed.
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Ray Guthrie [mailto:ra...@we...]
> > Sent: Tuesday, March 13, 2001 1:37 PM
> > To: Neulinger, Nathan R.
> > Subject: RE: RaQ2
> >
> >
> > When CGIs are run through the browser, the user is httpd.  I
> > logged in via
> > httpd via the command line, and the script runs just fine
> > when I execute it
> > (creates the directory).  But it's when I try to execute the
> > script via the
> > browser that causes the trouble.
> >
> > Thanks!
> > Ray.
> >
> > -----Original Message-----
> > From: Neulinger, Nathan R. [mailto:nn...@um...]
> > Sent: Tuesday, March 13, 2001 11:39 AM
> > To: 'Ray Guthrie'
> > Subject: RE: RaQ2
> >
> >
> > You need to determine what environment cobalt has configured.
> > They are not
> > running my cgiwrap. They are running some customized version
> > of theirs that
> > does not behave the same.
> >
> > I'd suggest capturing the output of the 'id' command executed
> > within the
> > cgi, and see who you are running as, and then also see what
> > directory you
> > are in, and see if the perms are appropriate.
> >
> > -- Nathan
> >
> > -----Original Message-----
> > From: Ray Guthrie [mailto:ra...@we...]
> > Sent: Tuesday, March 13, 2001 1:06 PM
> > To: nn...@um...
> > Subject: RaQ2
> >
> >
> > Hello,
> >
> > After calling Cobalt Services, and Calling my co-location for
> > help, and with
> > no luck, I was hoping that you would be able to help me.
> >
> > I have a small PERL script on one of my sites which looks like this:
> >
> > #!/usr/bin/perl
> >
> > mkdir('./testdir2', 0755);
> >
> > print "Content-type: text/html\n\n";
> > print "Done!";
> >
> > The problem is when I run this script from the command line,
> > it works just
> > fine, and creates the appropriate directory.  But if I try to
> > run it via the
> > browser, the script executes (no errors) but it does not create the
> > directory.
> >
> > No that I think of it, I think that I do not have any file
> > permissions for
> > CGI scripts. (Creating new files, deleting files, renaming
> > files, etc.)
> >
> > I was talking with a Cobalt tech last night (12 AM - 4AM),
> > and he said that
> > it must be something to do with the permissions of the CGI
> > Wrap, that it
> > gives to CGI scripts.
> >
> > To solve this problem, ultimately, I would rather leave CGI
> > Wrap enabled,
> > and just be able to write files and directories.  I would
> > like to know if I
> > can configure CGI wrap to allow this.
> >
> > You can find the script at:
> > http://www.webcustoms.com/cgi-bin/test.pl
> > <http://www.webcustoms.com/cgi-bin/test.pl>
> >
> > And the full path is:
> > /home/sites/site2/web/cgi-bin/test.pl
> >
> > Thanks!
> > Ray.
> >
> 

[cgiwrap-users] RE: RaQ2

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

You need to see exactly where the script is running from (what is the
current working directory when it runs) and exactly what uid+gid+auxgroups
it is running as, and what the permissions of the CWD are. 

This is NOT a problem with my software, it's a problem with their
customization of it and how they have it installed.

-- Nathan

> -----Original Message-----
> From: Ray Guthrie [mailto:ra...@we...]
> Sent: Tuesday, March 13, 2001 1:37 PM
> To: Neulinger, Nathan R.
> Subject: RE: RaQ2
> 
> 
> When CGIs are run through the browser, the user is httpd.  I 
> logged in via
> httpd via the command line, and the script runs just fine 
> when I execute it
> (creates the directory).  But it's when I try to execute the 
> script via the
> browser that causes the trouble.
> 
> Thanks!
> Ray.
> 
> -----Original Message-----
> From: Neulinger, Nathan R. [mailto:nn...@um...]
> Sent: Tuesday, March 13, 2001 11:39 AM
> To: 'Ray Guthrie'
> Subject: RE: RaQ2
> 
> 
> You need to determine what environment cobalt has configured. 
> They are not
> running my cgiwrap. They are running some customized version 
> of theirs that
> does not behave the same.
> 
> I'd suggest capturing the output of the 'id' command executed 
> within the
> cgi, and see who you are running as, and then also see what 
> directory you
> are in, and see if the perms are appropriate.
> 
> -- Nathan
> 
> -----Original Message-----
> From: Ray Guthrie [mailto:ra...@we...]
> Sent: Tuesday, March 13, 2001 1:06 PM
> To: nn...@um...
> Subject: RaQ2
> 
> 
> Hello,
> 
> After calling Cobalt Services, and Calling my co-location for 
> help, and with
> no luck, I was hoping that you would be able to help me.
> 
> I have a small PERL script on one of my sites which looks like this:
> 
> #!/usr/bin/perl
> 
> mkdir('./testdir2', 0755);
> 
> print "Content-type: text/html\n\n";
> print "Done!";
> 
> The problem is when I run this script from the command line, 
> it works just
> fine, and creates the appropriate directory.  But if I try to 
> run it via the
> browser, the script executes (no errors) but it does not create the
> directory.
> 
> No that I think of it, I think that I do not have any file 
> permissions for
> CGI scripts. (Creating new files, deleting files, renaming 
> files, etc.)
> 
> I was talking with a Cobalt tech last night (12 AM - 4AM), 
> and he said that
> it must be something to do with the permissions of the CGI 
> Wrap, that it
> gives to CGI scripts.
> 
> To solve this problem, ultimately, I would rather leave CGI 
> Wrap enabled,
> and just be able to write files and directories.  I would 
> like to know if I
> can configure CGI wrap to allow this.
> 
> You can find the script at:
> http://www.webcustoms.com/cgi-bin/test.pl
> <http://www.webcustoms.com/cgi-bin/test.pl>
> 
> And the full path is:
> /home/sites/site2/web/cgi-bin/test.pl
> 
> Thanks!
> Ray.
> 

Re: [cgiwrap-users] problem with ScriptAlias

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

G=E9rard,

A ScriptAlias refers to a directory, not a script or file. It's an alias
for a long path or a path not in the html tree, is all that is.

Ralph

On Fri, 9 Mar 2001, G=E9rard Gachelin wrote:

> Hello,
>=20
> I am using apache1.3.19, mod_fastcgi and cgiwrap
>=20
> Here is a part of the httpd.conf file, inside a virtual host definition
> :
>=20
>     ScriptAlias /cgi-bin/ "/usr/local/httpsd/cgi-bin/"
>=20
>     FastCgiWrapper      /usr/local/httpsd/cgi-bin/cgiwrap
>     FastCgiConfig
> =20
>     <Location /test>
>               SetHandler        fastcgi-script
>     </Location>
>=20
>       ScriptAlias /test  =20
> /usr/local/httpsd/cgi-bin/cgiwrap/sympa/test.fcgi
>=20
>=20
> A request to http://myserver/cgi-bin/cgiwrap/sympa/test.cgi is working
> fine.
>=20
> But a request to http://myserver/test doesn-t work.
> In error_log, cgiwrap send an html page containing :
> CGIWrap Error: Couldn't find user and script name, check your URL
>=20
> So the ScriptAlias /test is wrong but I don't know how to correct it.
>=20
> Thanks for any help
> --=20
> G=E9rard GACHELIN                          e-mail : gg...@un...=20
> Universit=E9 de la R=E9union                 T=E9l: 0262 93 82 72=20
> 15, Avenue Ren=E9 Cassin - BP 7151         Fax: 0262 93 82 60
> 97715 Saint-Denis MESSAG-CEDEX 9

[cgiwrap-users] problem with ScriptAlias

[G. <Ger...@un...>]

Hello,

I am using apache1.3.19, mod_fastcgi and cgiwrap

Here is a part of the httpd.conf file, inside a virtual host definition
:

    ScriptAlias /cgi-bin/ "/usr/local/httpsd/cgi-bin/"

    FastCgiWrapper      /usr/local/httpsd/cgi-bin/cgiwrap
    FastCgiConfig
 =

    <Location /test>
              SetHandler        fastcgi-script
    </Location>

      ScriptAlias /test   =

/usr/local/httpsd/cgi-bin/cgiwrap/sympa/test.fcgi


A request to http://myserver/cgi-bin/cgiwrap/sympa/test.cgi is working
fine.

But a request to http://myserver/test doesn-t work.
In error_log, cgiwrap send an html page containing :
CGIWrap Error: Couldn't find user and script name, check your URL

So the ScriptAlias /test is wrong but I don't know how to correct it.

Thanks for any help
-- =

G=E9rard GACHELIN                          e-mail : gg...@un... =

Universit=E9 de la R=E9union                 T=E9l: 0262 93 82 72 =

15, Avenue Ren=E9 Cassin - BP 7151         Fax: 0262 93 82 60
97715 Saint-Denis MESSAG-CEDEX 9

[cgiwrap-users] Help with compile

[Bill H. <bhe...@pa...>]

Hello,

Thank you for the quick response Nathan.

I am attaching the listing of the session from the shell console.
I must confess, I know very little about using the compiler and generating
a program.

I have no idea what fix I need to get "make" to work.  I know I need to get
a file called cgiwrap that I can move to the cgi-bin directory and change
the owner, permissions, etc.

Anu suggestions are appreciated.

Thanks,  Bill

RE: [cgiwrap-users] Help with compile

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

I don't see anything wrong with that output. What did configure say when you
ran it?

-- Nathan

> -----Original Message-----
> From: Bill Hedberg [mailto:bhe...@pa...]
> Sent: Sunday, February 25, 2001 9:22 PM
> To: cgi...@li...
> Subject: [cgiwrap-users] Help with compile
> 
> 
> Hello,
> I am trying to install CGIWRAP under RedHat 7.0
> 
> Following the instructions on using configure, I get the following 
> config.log file.  The Make file is not created.  Can anybody 
> help me figure
> out how to correct the
> problem??  Thanks,  Bill
> 
> 
> 
> BEGIN Listing of config.log:
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> configure:716: checking host system type
> configure:737: checking target system type
> configure:755: checking build system type
> configure:785: checking for gcc
> configure:862: checking whether the C compiler (gcc  ) works
> configure:876: gcc -o conftest    conftest.c  1>&5
> configure:896: checking whether the C compiler (gcc  ) is a 
> cross-compiler
> configure:901: checking whether we are using GNU C
> configure:910: gcc -E conftest.c
> configure:925: checking whether gcc accepts -g
> configure:953: checking whether make sets ${MAKE}
> configure:999: checking for perl
> configure:1035: checking for sigset
> configure:1063: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1086: checking for initgroups
> configure:1114: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1137: checking for setgroups
> configure:1165: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1188: checking for setgid
> configure:1216: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1239: checking for setuid
> configure:1267: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1290: checking for setegid
> configure:1318: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1341: checking for seteuid
> configure:1369: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1392: checking for setrgid
> configure:1420: gcc -o conftest -g -O2   conftest.c  1>&5
> /tmp/ccVLX6C9.o: In function `main':
> /root/cgiwrap-3.6.4/configure:1414: undefined reference to `setrgid'
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 1397 "configure"
> #include "confdefs.h"
> /* System header to define __stub macros and hopefully few prototypes,
>     which can conflict with char setrgid(); below.  */
> #include <assert.h>
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char setrgid();
> 
> int main() {
> 
> /* The GNU C library defines this for functions which it implements
>     to always fail with ENOSYS.  Some functions are actually named
>     something starting with __ and the normal name is an alias.  */
> #if defined (__stub_setrgid) || defined (__stub___setrgid)
> choke me
> #else
> setrgid();
> #endif
> 
> ; return 0; }
> configure:1443: checking for setruid
> configure:1471: gcc -o conftest -g -O2   conftest.c  1>&5
> /tmp/ccMWWPCd.o: In function `main':
> /root/cgiwrap-3.6.4/configure:1465: undefined reference to `setruid'
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 1448 "configure"
> #include "confdefs.h"
> /* System header to define __stub macros and hopefully few prototypes,
>     which can conflict with char setruid(); below.  */
> #include <assert.h>
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char setruid();
> 
> int main() {
> 
> /* The GNU C library defines this for functions which it implements
>     to always fail with ENOSYS.  Some functions are actually named
>     something starting with __ and the normal name is an alias.  */
> #if defined (__stub_setruid) || defined (__stub___setruid)
> choke me
> #else
> setruid();
> #endif
> 
> ; return 0; }
> configure:1494: checking for setregid
> configure:1522: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1545: checking for setreuid
> configure:1573: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1596: checking for setresgid
> configure:1624: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1647: checking for setresuid
> configure:1675: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1698: checking for perror
> configure:1726: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1749: checking for strerror
> configure:1777: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1800: checking for strdup
> configure:1828: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1851: checking for syslog
> configure:1879: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1902: checking for setrlimit
> configure:1930: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:1953: checking for putenv
> configure:1981: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:2004: checking for wait3
> configure:2032: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:2057: checking for local contact name
> configure:2088: checking for local contact email
> configure:2119: checking for local contact phone
> configure:2150: checking for local contact url
> configure:2181: checking for local site url
> configure:2212: checking for local cgiwrap docs
> configure:2244: checking for with-wall
> configure:2269: checking for installation group
> configure:2297: checking for installation directory
> configure:2322: checking for path to cgi scripts
> configure:2350: checking for httpd-user
> configure:2379: checking for check-httpd-user
> configure:2401: checking for report-rusage
> configure:2424: checking for strict-names
> configure:2451: checking for check-owner
> configure:2478: checking for check-group
> configure:2505: checking for check-setuid
> configure:2532: checking for check-setgid
> configure:2559: checking for check-group-writable
> configure:2586: checking for check-world-writable
> configure:2613: checking for check-symlink
> configure:2640: checking for minimum uid
> configure:2668: checking for logging-syslog
> configure:2695: checking for logging-file
> configure:2727: checking for script-subdirs
> configure:2755: checking for redirect-stderr
> configure:2783: checking for initgroups
> configure:2810: checking for setgroups
> configure:2838: checking for user directory rewrite
> configure:2862: checking for fixed-path-translated
> configure:2893: checking for setenv-path
> configure:2925: checking for setenv-tz
> configure:2962: checking for limit rlimit-cpu
> configure:2996: checking for limit rlimit-vmem
> configure:3030: checking for limit rlimit-as
> configure:3064: checking for limit rlimit-fsize
> configure:3098: checking for limit rlimit-data
> configure:3132: checking for limit rlimit-stack
> configure:3166: checking for limit rlimit-core
> configure:3200: checking for limit rlimit-rss
> configure:3234: checking for limit rlimit-nproc
> configure:3268: checking for limit rlimit-nofile
> configure:3302: checking for limit rlimit-memlock
> configure:3340: checking for allow-file
> configure:3366: checking for deny-file
> configure:3392: checking for host checking
> configure:3415: checking for shell checking
> configure:3500: checking for afs setpag() support
> configure:3559: checking how to run the C preprocessor
> configure:3580: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3620: checking for ANSI C header files
> configure:3633: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3700: gcc -o conftest -g -O2   conftest.c  1>&5
> configure:3727: checking for limits.h
> configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3727: checking for stdlib.h
> configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3727: checking for pwd.h
> configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3727: checking for string.h
> configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3727: checking for strings.h
> configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3767: checking for sys/resource.h
> configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3767: checking for sys/types.h
> configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3767: checking for sys/time.h
> configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3767: checking for unistd.h
> configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for syslog.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for fcntl.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for sys/stat.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for signal.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for ctype.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3807: checking for grp.h
> configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3847: checking for errno.h
> configure:3857: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:3847: checking for sys/wait.h
> configure:3857: gcc -E  conftest.c >/dev/null 2>conftest.out
> 
> 
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

[cgiwrap-users] Help with compile

[Bill H. <bhe...@pa...>]

Hello,
I am trying to install CGIWRAP under RedHat 7.0

Following the instructions on using configure, I get the following 
config.log file.  The Make file is not created.  Can anybody help me figure
out how to correct the
problem??  Thanks,  Bill



BEGIN Listing of config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:716: checking host system type
configure:737: checking target system type
configure:755: checking build system type
configure:785: checking for gcc
configure:862: checking whether the C compiler (gcc  ) works
configure:876: gcc -o conftest    conftest.c  1>&5
configure:896: checking whether the C compiler (gcc  ) is a cross-compiler
configure:901: checking whether we are using GNU C
configure:910: gcc -E conftest.c
configure:925: checking whether gcc accepts -g
configure:953: checking whether make sets ${MAKE}
configure:999: checking for perl
configure:1035: checking for sigset
configure:1063: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1086: checking for initgroups
configure:1114: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1137: checking for setgroups
configure:1165: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1188: checking for setgid
configure:1216: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1239: checking for setuid
configure:1267: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1290: checking for setegid
configure:1318: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1341: checking for seteuid
configure:1369: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1392: checking for setrgid
configure:1420: gcc -o conftest -g -O2   conftest.c  1>&5
/tmp/ccVLX6C9.o: In function `main':
/root/cgiwrap-3.6.4/configure:1414: undefined reference to `setrgid'
collect2: ld returned 1 exit status
configure: failed program was:
#line 1397 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char setrgid(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char setrgid();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_setrgid) || defined (__stub___setrgid)
choke me
#else
setrgid();
#endif

; return 0; }
configure:1443: checking for setruid
configure:1471: gcc -o conftest -g -O2   conftest.c  1>&5
/tmp/ccMWWPCd.o: In function `main':
/root/cgiwrap-3.6.4/configure:1465: undefined reference to `setruid'
collect2: ld returned 1 exit status
configure: failed program was:
#line 1448 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char setruid(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char setruid();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_setruid) || defined (__stub___setruid)
choke me
#else
setruid();
#endif

; return 0; }
configure:1494: checking for setregid
configure:1522: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1545: checking for setreuid
configure:1573: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1596: checking for setresgid
configure:1624: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1647: checking for setresuid
configure:1675: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1698: checking for perror
configure:1726: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1749: checking for strerror
configure:1777: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1800: checking for strdup
configure:1828: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1851: checking for syslog
configure:1879: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1902: checking for setrlimit
configure:1930: gcc -o conftest -g -O2   conftest.c  1>&5
configure:1953: checking for putenv
configure:1981: gcc -o conftest -g -O2   conftest.c  1>&5
configure:2004: checking for wait3
configure:2032: gcc -o conftest -g -O2   conftest.c  1>&5
configure:2057: checking for local contact name
configure:2088: checking for local contact email
configure:2119: checking for local contact phone
configure:2150: checking for local contact url
configure:2181: checking for local site url
configure:2212: checking for local cgiwrap docs
configure:2244: checking for with-wall
configure:2269: checking for installation group
configure:2297: checking for installation directory
configure:2322: checking for path to cgi scripts
configure:2350: checking for httpd-user
configure:2379: checking for check-httpd-user
configure:2401: checking for report-rusage
configure:2424: checking for strict-names
configure:2451: checking for check-owner
configure:2478: checking for check-group
configure:2505: checking for check-setuid
configure:2532: checking for check-setgid
configure:2559: checking for check-group-writable
configure:2586: checking for check-world-writable
configure:2613: checking for check-symlink
configure:2640: checking for minimum uid
configure:2668: checking for logging-syslog
configure:2695: checking for logging-file
configure:2727: checking for script-subdirs
configure:2755: checking for redirect-stderr
configure:2783: checking for initgroups
configure:2810: checking for setgroups
configure:2838: checking for user directory rewrite
configure:2862: checking for fixed-path-translated
configure:2893: checking for setenv-path
configure:2925: checking for setenv-tz
configure:2962: checking for limit rlimit-cpu
configure:2996: checking for limit rlimit-vmem
configure:3030: checking for limit rlimit-as
configure:3064: checking for limit rlimit-fsize
configure:3098: checking for limit rlimit-data
configure:3132: checking for limit rlimit-stack
configure:3166: checking for limit rlimit-core
configure:3200: checking for limit rlimit-rss
configure:3234: checking for limit rlimit-nproc
configure:3268: checking for limit rlimit-nofile
configure:3302: checking for limit rlimit-memlock
configure:3340: checking for allow-file
configure:3366: checking for deny-file
configure:3392: checking for host checking
configure:3415: checking for shell checking
configure:3500: checking for afs setpag() support
configure:3559: checking how to run the C preprocessor
configure:3580: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3620: checking for ANSI C header files
configure:3633: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3700: gcc -o conftest -g -O2   conftest.c  1>&5
configure:3727: checking for limits.h
configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3727: checking for stdlib.h
configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3727: checking for pwd.h
configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3727: checking for string.h
configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3727: checking for strings.h
configure:3737: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3767: checking for sys/resource.h
configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3767: checking for sys/types.h
configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3767: checking for sys/time.h
configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3767: checking for unistd.h
configure:3777: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for syslog.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for fcntl.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for sys/stat.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for signal.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for ctype.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3807: checking for grp.h
configure:3817: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3847: checking for errno.h
configure:3857: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:3847: checking for sys/wait.h
configure:3857: gcc -E  conftest.c >/dev/null 2>conftest.out

[cgiwrap-users] CGI::Carp query - on RaQ4

[Roger H. <ro...@ea...>]

I'm getting unexpected behaviour from CGI::Carp under cgiwrap on a RaQ4.

FatalsToBrowser gives no output from carp, and reports a software error on
die.
Without FatalsToBrowser, I get 'Premature end of script headers', and
'Internal Server Error' at the browser..

Is this behaviour known, and can anyone advise me concerning it?

The problem arises both with the Cobalt installation and with the open
version.

- Roger -

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Ian F. <ia...@mi...>]

Roger Haslock wrote:

> [ on the RaQ]
> I cannot see that changing system files will void the parts and labour bit,
> and I cannot see that the 30 days consulting will give any insight into the
> consequences of such changed files. If this is not correct, it would be nice
> to know where we stand.

I agree.

If the RaQ was sold as a webserver, with the implication that you could
do with it all that a normal Linux / Apache etc webserver will do, and
then you find that you have in fact to edit configurations manually,
then I think at least in the UK you'd have a reasonable case. What would
happen in a court case I've no idea, but I do think it would be a
reasonable customer-relations point.

In any case, if customer support means telling customers to reinstall to
factory default, without a means of resetting all the configurations and
websites from a backup, then how much is it worth anyway?

Regards,

Ian.

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Roger H. <ro...@ea...>]

Of course, I' talking through my hat. I hadn't looked up anything.

I have now found, on Cobalt's website,
http://emea.cobalt.com/products/raq/faq.raq4.html#17

>What about RaQ 4's warranty and support?
>30 day consulting, 1 year parts and labor. Additional warranty and support
available.

Also the message, when logging on as root:-
* NOTICE TO ROOT USER: Changes to system files may affect  *
* your warranty. Please consult your warranty card for details. *

I like the advisory 'may'.

I cannot see that changing system files will void the parts and labour bit,
and I cannot see that the 30 days consulting will give any insight into the
consequences of such changed files. If this is not correct, it would be nice
to know where we stand.

- Roger -

----- Original Message -----
From: "James Moore" <jim...@fi...>
To: <cgi...@li...>; "Roger Haslock"
<ro...@ea...>
Sent: Thursday, February 15, 2001 7:16 PM
Subject: Re: [cgiwrap-users] RE: cgi-wrap security issue


> On 15 Feb 2001, Roger Haslock wrote:
>
> > I hardly think the warranty issue is significant. Cobalt are just saying
> > they won't support their software if its been fiddled with.
>
> No - that's not what they're saying. And I think it may be significant
> to someone who loses the warranty protection on their server because
> they weren't aware of the policy.
>
> Regards,
> James Moore
>

[cgiwrap-users] mod_bandwidth

[Quek <qu...@si...>]

Hi!

After I complied Apache with mod_bandwidth, all my forms stop passing
parameters to my cgi scripts. Anyone had any idea what's wrong?

Quek

Re: [cgiwrap-users] RE: cgi-wrap security issue

[James M. <jim...@fi...>]

On 15 Feb 2001, Roger Haslock wrote:

> I hardly think the warranty issue is significant. Cobalt are just saying
> they won't support their software if its been fiddled with.

No - that's not what they're saying. And I think it may be significant 
to someone who loses the warranty protection on their server because 
they weren't aware of the policy.

Regards,
James Moore

Re: [cgiwrap-users] RE: cgi-wrap security issue

[I. P. R. <p....@ne...>]

I can't help but feel that here is an issue
that will never go away.

>>Cobalt are just saying they won't support 
>>their software if its been fiddled with.

There is something "almost"  funny  in this 
fact, since it puts the far more honourable
Nathan in the position of having to support 
his software because they fiddled with it.

Should there  not be a  clause added to the
license included with the source  code that 
warnings from the  original developer about 
security issues should be heeded (or a very
clear statement should be made that the new
software has no connections whatsoever with
the source code from which it is derived).

The frustration from this situation is very
obvious but it opens a window on a far more
serious issue. The foundation  of  security 
software is trust. If you use a platform on
which cgiwrap is installed you trust in its
capabilities and stay aware for its  flaws.

For writers of closely derivative  software
to ignore any warning from the developer is
clearly wrong. Perhaps you should cite this 
case to gnu.org as an addition for a future
revision or indeed as a reason enough for a
branched version specifically  for security
software. 

--
I.P. Robson

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Ian F. <ia...@mi...>]

"Neulinger, Nathan R." wrote:
> 
> Yeah, you can add your own cgiwrap, just edit some of the files in
> /etc/httpd/. Pretty simple. I don't think they use cgiwrap for any
> serverwide stuff other than scripts installed by users.

Ah - great!

I hope it's simple, since I haven't (yet) a clue where to start, but
presumably I'll find that sort of thing on the website.

Cheers,

Ian.

-- 
**********************************************************************
Ian Fantom  -  Mintex Computer Services Ltd 
   ia...@mi...
   http://www.mintex.demon.co.uk/ian 
   Tel: 01635 38592
***********************************************************************

RE: [cgiwrap-users] RE: cgi-wrap security issue

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

Yeah, you can add your own cgiwrap, just edit some of the files in
/etc/httpd/. Pretty simple. I don't think they use cgiwrap for any
serverwide stuff other than scripts installed by users.

-- Nathan

> -----Original Message-----
> From: Ian Fantom [mailto:ia...@mi...]
> Sent: Thursday, February 15, 2001 8:41 AM
> To: cgi...@li...
> Subject: Re: [cgiwrap-users] RE: cgi-wrap security issue
> 
> 
> James Moore wrote:
> 
> > Be careful. Cobalt's official policy of treating customers like
> > assholes requires that they void your warranty if you replace or add
> > any software from other sources.
> 
> ... and their warrenty support consists of saying to 
> reinstall the OS to
> factory default, which wipes your disc, without an obvious way of
> reinstalling all the configurations that Cobalt software has 
> control of.
> So we had to do all by setting it all up from scratch again.
> 
> We didn't have access to the source code either, but it 
> seemed to be the
> Cobalt cgiwrap that was causing the problem.
> 
> Is it easy to bypass the Cobalt cgiwrap and install my own 
> handler name
> with a different version of cgiwrap. I can access cgi-bin outside the
> web area with the cgi-script handler, so perhaps I could just install
> another handler and not touch Cobalt's cgiwrap?
> 
> Regards,
> 
> Ian.
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Ian F. <ia...@mi...>]

James Moore wrote:

> Be careful. Cobalt's official policy of treating customers like
> assholes requires that they void your warranty if you replace or add
> any software from other sources.

... and their warrenty support consists of saying to reinstall the OS to
factory default, which wipes your disc, without an obvious way of
reinstalling all the configurations that Cobalt software has control of.
So we had to do all by setting it all up from scratch again.

We didn't have access to the source code either, but it seemed to be the
Cobalt cgiwrap that was causing the problem.

Is it easy to bypass the Cobalt cgiwrap and install my own handler name
with a different version of cgiwrap. I can access cgi-bin outside the
web area with the cgi-script handler, so perhaps I could just install
another handler and not touch Cobalt's cgiwrap?

Regards,

Ian.

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Roger H. <ro...@ea...>]

I hardly think the warranty issue is significant. Cobalt are just saying
they won't support their software if its been fiddled with.

- Roger -

----- Original Message -----
From: "James Moore" <jim...@fi...>
To: "Ian Fantom" <ia...@mi...>;
<cgi...@li...>
Sent: Thursday, February 15, 2001 2:08 PM
Subject: Re: [cgiwrap-users] RE: cgi-wrap security issue


> On 15 Feb 2001, Ian Fantom wrote:
>
> > > No, I complained to them about that a while back but they never
rewrote the
> > > alert message. Cobalt had a modified cgiwrap that was very insecure.
That is
> > > only an issue if you're using cobalts custom version.
> > >
> >
> > Oh dear! I am. I've just joined the list because I got a Cobalt RaQ3i in
> > a hurry, which brilliantly enabled me to set up web sites quickly, but
> > now I'm struggling with the cgiwrap.
> >
> > I find I can only enable cgi scripts through cgiwrap if they are in the
> > web area. I want to create a cgi-bin directory outside the web area. Is
> > this seen as a security issue?
> >
> > What are the other security issues on the RaQ?
> >
> > What can I do about that? Like install a different version of cgiwrap?
>
> Be careful. Cobalt's official policy of treating customers like
> assholes requires that they void your warranty if you replace or add
> any software from other sources.
>
> Regards,
> James Moore
>
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] RE: cgi-wrap security issue

[James M. <jim...@fi...>]

On 15 Feb 2001, Ian Fantom wrote:

> > No, I complained to them about that a while back but they never rewrote the
> > alert message. Cobalt had a modified cgiwrap that was very insecure. That is
> > only an issue if you're using cobalts custom version.
> >
> 
> Oh dear! I am. I've just joined the list because I got a Cobalt RaQ3i in
> a hurry, which brilliantly enabled me to set up web sites quickly, but
> now I'm struggling with the cgiwrap.
> 
> I find I can only enable cgi scripts through cgiwrap if they are in the
> web area. I want to create a cgi-bin directory outside the web area. Is
> this seen as a security issue?
> 
> What are the other security issues on the RaQ?
> 
> What can I do about that? Like install a different version of cgiwrap?

Be careful. Cobalt's official policy of treating customers like 
assholes requires that they void your warranty if you replace or add 
any software from other sources.

Regards,
James Moore

Re: [cgiwrap-users] RE: cgi-wrap security issue

[Ian F. <ia...@mi...>]

"Neulinger, Nathan R." wrote:
> 
> No, I complained to them about that a while back but they never rewrote the
> alert message. Cobalt had a modified cgiwrap that was very insecure. That is
> only an issue if you're using cobalts custom version.
>

Oh dear! I am. I've just joined the list because I got a Cobalt RaQ3i in
a hurry, which brilliantly enabled me to set up web sites quickly, but
now I'm struggling with the cgiwrap.

I find I can only enable cgi scripts through cgiwrap if they are in the
web area. I want to create a cgi-bin directory outside the web area. Is
this seen as a security issue?

What are the other security issues on the RaQ?

What can I do about that? Like install a different version of cgiwrap?

Many thanks,

Ian.

[cgiwrap-users] RE: cgi-wrap security issue

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

No, I complained to them about that a while back but they never rewrote the
alert message. Cobalt had a modified cgiwrap that was very insecure. That is
only an issue if you're using cobalts custom version.

-- Nathan

> -----Original Message-----
> From: Mark Shifman [mailto:mar...@ya...]
> Sent: Wednesday, February 14, 2001 1:36 PM
> To: nn...@um...
> Subject: cgi-wrap security issue
> 
> 
> Hi: 
> I have recently run nessus security scanner (nessus (Nessus) 
> 1.0.7 for Linux  on
>  my server and it gave me this message:
> 
> .. Vulnerability found on port www (80/tcp) : 
> 
> 
>     'cgiwrap' is installed. This CGI has
>      a well known security flaw that lets anyone execute arbitrary
>      commands with the privileges of the http daemon (root or nobody).
>     
>     ** Note that all version of cgiwrap are not affected
>        by this problem ! Consult your vendor.
>        
>     Solution :  remove it from /cgi-bin.
>     
>     Risk factor :
>      Serious
> 
> Is this something to worry about? Are there recent versions 
> of cgiwrap that fix this?
> 
> Thanks.
> 
> 
> -- 
>  Mark Shifman MD. Ph.D.
>  Yale Center for Medical Informatics
>  Phone (203)764-6723
>  mar...@ya...
> 

Re: [cgiwrap-users] Re: cgiwrap and apache

[Roger H. <ro...@ea...>]

Sirs

I would like to do the same thing, with my eyes on mod_vhost_alias. Ralph,
Can I offer help in the form of a second test site. Nathan, where should we
publish results?

Regards
- Roger C Haslock -

----- Original Message -----
From: "Ralph Huntington" <rj...@mo...>
To: "Nathan Neulinger" <nn...@um...>
Cc: <cg...@un...>
Sent: Saturday, February 10, 2001 3:31 PM
Subject: Re: [cgiwrap-users] Re: cgiwrap and apache


> Thank you. I'll do some experimentation. -=r=-
>
> On Sat, 10 Feb 2001, Nathan Neulinger wrote:
>
> > Ralph Huntington wrote:
> > >
> > > Nathan,
> > >
> > > I must apologize for writing to you directly, but I have asked this on
the
> > > list twice and not received useful responses. I wonder if what I am
asking
> > > is even possible.
> > >
> > > Is there a way to configure cgiwrap in httpd.conf such that a separate
> > > ScriptAlias directive is not needed for each virtualhost, meaning the
path
> > > info will not be the artifical
> > >
> > >         /apache/cgi-bin/cgiwrap/$user/$dir/$script
> > >
> > > but rather a plain old path like
> > >
> > >         /$dir/$script
> > >
> > > In other words, can cgiwrap be enabled universally in httpd.conf,
perhaps
> > > with an AddHandler directive?
> > >
> > > Thank you very much for any insight you may provide.    - Ralph
> >
> > There are various things you can do with mod_rewrite to do that sort of
> > thing. But you'd likely need to come up with some sort of map though,
> > since it has to know what the base userid is for the vhost. If your
> > vhost base path is always something consistent like:
> >
> > /users/userid/vhost_html
> >
> > you might be able to rig up a rewrite rule to handle it.
> >
> > BTW - and to the list - I'm always more than happy to dig detailed into
> > problems, or customize cgiwrap for an individual situation on a
> > consulting basis.
> >
> > -- Nathan
> >
> > ------------------------------------------------------------
> > Nathan Neulinger                       EMail:  nn...@um...
> > University of Missouri - Rolla         Phone: (573) 341-4841
> > CIS - Systems Programming                Fax: (573) 341-4216
> >
> > _______________________________________________
> > cgiwrap-users mailing list
> > cgi...@li...
> > http://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> >
>
>
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] Re: cgiwrap and apache

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

Thank you. I'll do some experimentation. 	-=r=-

On Sat, 10 Feb 2001, Nathan Neulinger wrote:

> Ralph Huntington wrote:
> > 
> > Nathan,
> > 
> > I must apologize for writing to you directly, but I have asked this on the
> > list twice and not received useful responses. I wonder if what I am asking
> > is even possible.
> > 
> > Is there a way to configure cgiwrap in httpd.conf such that a separate
> > ScriptAlias directive is not needed for each virtualhost, meaning the path
> > info will not be the artifical
> > 
> >         /apache/cgi-bin/cgiwrap/$user/$dir/$script
> > 
> > but rather a plain old path like
> > 
> >         /$dir/$script
> > 
> > In other words, can cgiwrap be enabled universally in httpd.conf, perhaps
> > with an AddHandler directive?
> > 
> > Thank you very much for any insight you may provide.    - Ralph
> 
> There are various things you can do with mod_rewrite to do that sort of
> thing. But you'd likely need to come up with some sort of map though,
> since it has to know what the base userid is for the vhost. If your
> vhost base path is always something consistent like:
> 
> /users/userid/vhost_html
> 
> you might be able to rig up a rewrite rule to handle it. 
> 
> BTW - and to the list - I'm always more than happy to dig detailed into
> problems, or customize cgiwrap for an individual situation on a
> consulting basis. 
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> CIS - Systems Programming                Fax: (573) 341-4216
> 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

[cgiwrap-users] Re: cgiwrap and apache

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

Ralph Huntington wrote:
> 
> Nathan,
> 
> I must apologize for writing to you directly, but I have asked this on the
> list twice and not received useful responses. I wonder if what I am asking
> is even possible.
> 
> Is there a way to configure cgiwrap in httpd.conf such that a separate
> ScriptAlias directive is not needed for each virtualhost, meaning the path
> info will not be the artifical
> 
>         /apache/cgi-bin/cgiwrap/$user/$dir/$script
> 
> but rather a plain old path like
> 
>         /$dir/$script
> 
> In other words, can cgiwrap be enabled universally in httpd.conf, perhaps
> with an AddHandler directive?
> 
> Thank you very much for any insight you may provide.    - Ralph

There are various things you can do with mod_rewrite to do that sort of
thing. But you'd likely need to come up with some sort of map though,
since it has to know what the base userid is for the vhost. If your
vhost base path is always something consistent like:

/users/userid/vhost_html

you might be able to rig up a rewrite rule to handle it. 

BTW - and to the list - I'm always more than happy to dig detailed into
problems, or customize cgiwrap for an individual situation on a
consulting basis. 

-- Nathan

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