cgiwrap-users Mailing List for CGIWrap (Page 21)
Brought to you by:
nneul
Menu
▾
▴
cgiwrap-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(21) |
Sep
(23) |
Oct
(4) |
Nov
(15) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(5) |
Feb
(19) |
Mar
(19) |
Apr
(13) |
May
(12) |
Jun
(23) |
Jul
(6) |
Aug
(16) |
Sep
(6) |
Oct
(31) |
Nov
(23) |
Dec
(28) |
| 2002 |
Jan
(4) |
Feb
(9) |
Mar
(6) |
Apr
(23) |
May
(29) |
Jun
(16) |
Jul
(10) |
Aug
(41) |
Sep
(16) |
Oct
(8) |
Nov
(7) |
Dec
(7) |
| 2003 |
Jan
(13) |
Feb
(30) |
Mar
(6) |
Apr
(12) |
May
(23) |
Jun
(12) |
Jul
(11) |
Aug
(20) |
Sep
|
Oct
|
Nov
(10) |
Dec
(8) |
| 2004 |
Jan
(1) |
Feb
(11) |
Mar
(3) |
Apr
(10) |
May
(6) |
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(2) |
Dec
|
| 2005 |
Jan
(7) |
Feb
|
Mar
(7) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(12) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(14) |
Dec
|
| 2008 |
Jan
(5) |
Feb
(10) |
Mar
|
Apr
(12) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: Frank T. <th...@in...> - 2002-01-28 09:32:13
|
Hello Joe,
> On Thu, 17 Jan 2002, Frank Thommen wrote:
> > use it with shell script (sh, tcsh or csh) we get "Internal Server Error".
> > Looking at them with cgiwrapd reveals, that there is absolutely no
> > output from the scripts.
> Use it in debug mode.
I did ("Looking at them with cgiwrapd.."). There is no output at all from the
script. Not a single character.
> You're not generating clean headers.
I'm absolutely sure that the headers are correct. Also, they work when the
script is executed as cgi-bin w/o using cgiwrap.>
frank
----------
Frank Thommen, IT Support Group, D-INFK, ETH Zuerich
E-Mail: th...@in...; Tel: +41-1-63 27208 (Mon-Thu)
Web: http://www.isg.inf.ethz.ch
----------
|
|
From: Will <dir...@da...> - 2002-01-24 22:01:03
|
Hi. I'm new to the list and CGIWrap. I have installed Apache with SUEXEC support and installed PHP as a normal executable. I downloaded cgiwrap-3.7.1.tar.gz and patched it with cgiwrap-3.7.1-p6-withphp.diff.gz. CGIWRAP seems to work fine with cgi scripts, however when I attempt to load a php script I get the "CGIWrap is not setuid" error. I used 'make install' with CGIWRAP and the executables are setuid. I'm not sure what I did wrong, but any help with fixing it would be appreciated. thanks! -- Will |
|
From: Joe H. <on...@dc...> - 2002-01-24 20:47:58
|
On Thu, 17 Jan 2002, Frank Thommen wrote: > Hello, > > we use CGIWrap since a long time with Perl scripts. However, when we want to > use it with shell script (sh, tcsh or csh) we get "Internal Server Error". > Looking at them with cgiwrapd reveals, that there is absolutely no output from > the scripts. The same scripts work w/o problems, when installed as "normal" > CGI scripts run directly by the webserver (Apache). > > Any hints? Use it in debug mode. You're not generating clean headers. ----- Joe Hourcle |
|
From: Frank T. <th...@in...> - 2002-01-17 16:24:21
|
Hello,
we use CGIWrap since a long time with Perl scripts. However, when we want to
use it with shell script (sh, tcsh or csh) we get "Internal Server Error".
Looking at them with cgiwrapd reveals, that there is absolutely no output from
the scripts. The same scripts work w/o problems, when installed as "normal"
CGI scripts run directly by the webserver (Apache).
Any hints?
TIA
Frank Thommen
** Problems, questions, feedback? Mail to su...@in... **
----------
Frank Thommen, Informatik Support Gruppe, D-INFK, ETH Zuerich
E-Mail: th...@in...; Tel: +41-1-63 27208 (Mo-Do)
Web: http://www.isg.inf.ethz.ch
----------
|
|
From: Kyle <ky...@cc...> - 2001-12-20 22:21:26
|
Frank, you're a genius! You can see your script work under CGIWrap on my same server as before at: http://www.otbnetworks.com/cgi-bin/frank.cgi I see from dumping my environment within CGIWrap that /bin is not listed in the path. Gosh I can't believe I missed that. :( I'll make the appropriate changes and let the group know how it turns out. -Kyle Frank Louwers wrote: > > > > > In my PERL scripts, I use commands like these commonly: > > > $hostname = `hostname`; > > > $dir = `pwd`; > > > $date = `date +%c`; > > Very stupid question, but try this: > > #!/usr/bin/perl > print "Content-type: text/html\n\n"; > print "<HTML><BODY>testink\n"; > $hostname = `/bin/hostname`; > print "hostname: $hostname\n"; > > as a script and tell me what you see ... > > Frank |
|
From: Neulinger, N. <nn...@um...> - 2001-12-20 21:52:14
|
I read the cgiwrap list, there's no need to send to me personally. They work find with cgiwrap, it's something to do with your system or how you configured cgiwrap/etc. I routinely use backticks in cgiwrap run scripts without any problems. I don't have any good suggestions on what to try as I have never had this problem on any machine that I've tried it on. Running under cgiwrapd should give useful diagnostics if any error is happening. You can try outputting the contents of %ENV in each script as well. You might also try stracing the apache process and watching cgiwrap execute the script to see if some system call is failing when it tries to execute the date command. I'd bet you have some sort of memory limit or similar set that is preventing the fork, but without digging into it on your machine, I can't be sure. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Kyle [mailto:ky...@cc...] > Sent: Thursday, December 20, 2001 3:43 PM > To: Neulinger, Nathan > Subject: CGIWrap (bug?) user group unsure > Importance: High > > > Mr. Neulinger, > > I had to e-mail you personally, because I and the CGIWrap group were > unable to resolve this issue. I have tried to make this as brief as > possible. Here is my original posting plus some extra info: > > In my PERL scripts, I use commands like these commonly: > $hostname = `hostname`; > $dir = `pwd`; > $date = `date +%c`; > > All of these functions return null when run under cgiwrap, > but work fine > when cgiwrap is bypassed. > > 1) Why don't they work under CGIWrap? > 2) What can I do to get around this problem? > > I need these functions (and others). If it is okay for user "Kyle" to > do these functions, then why can't my script run them under CGIWrap as > user "Kyle"? > > Here's how I know CGIWrap causing the problem. If I run the > script from the command line it works. If I run it from http > via apache > via cgiwrap, the back ticks do not work (return null). If I > change the > virtual host in apache to be a regular old script (i.e. no cgiwrap), I > can run it just fine from http via apache. I'm running > cgiwrap 3.7.1 on > redhat 7.1 with apache 1.3.22. Does ANYONE have any ideas on > this? I'm > getting desperate here. > > Also, the log files look like this (first line returned null, > the second > returned the data correctly): > wfp86007 cgi-bin/path.cgi <NULL> 10.1.1.202 > <NULL> > ok > Thu Dec 20 13:55:10 2001 > > wfp86007 cgi-bin/path.cgi <NULL> 10.1.1.202 > <NULL> > ok > Thu Dec 20 14:11:23 2001 > > I put this *exact* script (below) in two of my virtual hosts. > I turned > CGIwrap > off for one and left it enabled on the other. Here are the two URLs: > http://www.glorianceramics.com/cgi-bin/ralph.cgi (cgiwrap off) > http://www.otbnetworks.com/cgi-bin/ralph.cgi (cgiwrap on) > > Both are unpublished sites being set up at the moment. Here is the > script: > #!/usr/bin/perl > # > > $date = `date`; chomp($date); > > print "Content-type:text/html\n\n"; > print <<EOP; > <html><head><title>$date</title></head> > <body bgcolor=ffffcc><br><font face=arial> > $date > <br></font></body></html> > EOP > > Here are the switches I used when building CGIWrap in case you think I > forgot one, or did one incorrectly: > > --with-local-contact-email=su...@ot... > --with-local-contact-phone=1- > 770-476-7322 --with-local-site-url=www.otbnetworks.com > --with-install-group=apac > he --with-cgi-dir=. --with-httpd-user=apache > --with-logging-file=/var/log/cgi.lo > g --with-setenv-path=/sbin:/usr/sbin:/usr/bin --with-rlimit-cpu=3600 > --with-inst > all-dir=/utils/cgi-bin > > Any help you can provide would be greatly appreciated!!!! :) > > -Kyle > |
|
From: Kyle <ky...@cc...> - 2001-12-20 20:20:59
|
Thanks for the quick reply, Ralph. Here's why I think it is CGIWrap causing the problem. If I run the script from the command line it works. If I run it from http via apache via cgiwrap, the back ticks do not work (return null). If I change the virtual host in apache to be a regular old script (i.e. no cgiwrap), I can run it just fine from http via apache. I'm running cgiwrap 3.7.1 on redhat 7.1 with apache 1.3.22. Does ANYONE have any ideas on this? I'm getting desperate here. Also, the log files look like this (first line returned null, the second returned the data correctly): wfp86007 cgi-bin/path.cgi <NULL> 10.1.1.202 <NULL> ok Thu Dec 20 13:55:10 2001 wfp86007 cgi-bin/path.cgi <NULL> 10.1.1.202 <NULL> ok Thu Dec 20 14:11:23 2001 -Kyle Ralph Huntington wrote: > > I use this type of syntax in my perl scripts also and they work fine under > cgiwrap. There must be some configuration issue (or something). Sorry I > don't have a clue what that something might be, but I can say without > reservation that the "shell escaped" commands you refer to work with > cgiwrap. > > On Thu, 20 Dec 2001, Kyle wrote: > > > In my PERL scripts, I use commands like these commonly: > > $hostname = `hostname`; > > $dir = `pwd`; > > $date = `date +%c`; > > > > All of these functions return null when run under cgiwrap, but work fine > > when cgiwrap is bypassed. > > > > 1) Why don't they work under CGIWrap? > > > > 2) What can I do to get around this problem? > > > > I need these functions (and others). If it is okay for user "Kyle" to > > do these functions, then why can't my script run them under CGIWrap as > > user "Kyle"? > > > > PLEASE help me! > > > > -Kyle > > > > _______________________________________________ > > cgiwrap-users mailing list > > cgi...@li... > > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > > |
|
From: Ralph H. <rj...@mo...> - 2001-12-20 19:59:12
|
I use this type of syntax in my perl scripts also and they work fine under cgiwrap. There must be some configuration issue (or something). Sorry I don't have a clue what that something might be, but I can say without reservation that the "shell escaped" commands you refer to work with cgiwrap. On Thu, 20 Dec 2001, Kyle wrote: > In my PERL scripts, I use commands like these commonly: > $hostname = `hostname`; > $dir = `pwd`; > $date = `date +%c`; > > All of these functions return null when run under cgiwrap, but work fine > when cgiwrap is bypassed. > > 1) Why don't they work under CGIWrap? > > 2) What can I do to get around this problem? > > I need these functions (and others). If it is okay for user "Kyle" to > do these functions, then why can't my script run them under CGIWrap as > user "Kyle"? > > PLEASE help me! > > -Kyle > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > |
|
From: Kyle <ky...@cc...> - 2001-12-20 19:10:09
|
In my PERL scripts, I use commands like these commonly: $hostname = `hostname`; $dir = `pwd`; $date = `date +%c`; All of these functions return null when run under cgiwrap, but work fine when cgiwrap is bypassed. 1) Why don't they work under CGIWrap? 2) What can I do to get around this problem? I need these functions (and others). If it is okay for user "Kyle" to do these functions, then why can't my script run them under CGIWrap as user "Kyle"? PLEASE help me! -Kyle |
|
From: Neulinger, N. <nn...@um...> - 2001-12-19 20:59:12
|
Not sure... if it's a new site - you might temporarily try finding the place in the httpd conf file where it says ".../cgiwrap" and temporarily change it to ".../cgiwrapd" and then try running it to see if it gives you any useful diagnostics. That should indicate what it is trying to run and where from. As this is a RaQ specific issue, I can't really provide much help (my policy has been to only provide detailed help on RaQ's on a hourly basis, cause they are generally such a pain). -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Jaret Wilson [mailto:pha...@ww...] > Sent: Wednesday, December 19, 2001 1:54 PM > To: Neulinger, Nathan > Subject: CGIWrap question > > > Nathan, > > I hate to bother you with my CGIWrap question, but I can't > seem to find > the answer anywhere online. > > I'm trying to run a perl script, and getting the error you see here: > http://www.4literature.net/ipn.cgi > It suggests that I may have uploaded the script in binary, or > that I may > have Control-M's in the script. However, neither of these > things is true. > The script runs just fine from the command line. The error > message also > suggests a problem with the #! line, which is #!/usr/bin/perl > though I've > also tried other variations. > > The script is on a RAQ3 which I have root access to. It is owned by > "admin" as is the directory that it's in which is > /home/sites/www.4literature.net/web . I'm relatively new to linux, so > I'm about out of ideas here. Any idea what the problem might be? > > Thanks, > Jaret Wilson > > > |
|
From: Nathan N. <nn...@um...> - 2001-12-16 19:18:47
|
Yes, chroot in cgiwrap is an extremely ugly, and barely functional hack. For 99% of the world, chrooting cgi is just plain impossible due to scripts needing to use perl, etc. The chroot hack was just a bare bones minimal hack. If you use any 'simple' chroot that chroots to user home dir/etc. you're going to break most scripts out there. The support that is in cgiwrap will yield an almost completely functional chroot environment, provided it's set up properly. (If you read the chroot documentation, it explains exactly what environment is needed for the chroot support.) If you're going to be doing much, please direct these to the cgiwrap mailing list, as others have similar patches, and would be much more in tune to the needs. I don't use the chroot functionality, as I think it's a pain and doesn't really accomplish much. With regards to your patch below, I would most likely not apply it - as it completely changes the way chrooting is done, and would not be functional for MOST of the scripts in existence. If you want to make a clean patch that implements an additional (in addition to the current chroot support) chroot mechanism, that I might consider applying. (Feel free to send cvs diffs of any of the web pages/etc. - the entire web site/etc. is in the cgiwrap tarball/cvs.) -- Nathan Mr Yowler wrote: > > I can see that I'm about to become a thorn in your ass... :) > > Chrooting, under CGIwrap, appears to me, to contain a bug or two - > either that, or the chroot support is horribly underdeveloped, as > compared to the rest of the code. > > I have been running through your source code, to try to figure out why > it seems to be impossible to chroot my scripts, and still have CGIwrap > find them, when I want to run them, and what I have discovered, is > that you are figuring out the location of my scripts, in my filesystem > tree, so that you can verify that they exist, before you chroot into > the filesystem tree from which the script is to be run. You then use > the path to the script, as determined *before* the chroot, to attempt > to chdir() into the scriptPath's directory, now that we are in the > chrooted filesystem. Also, the chroot directory seems very rigid - it > is whatever it was configured to, with --with-chroot=PATH. It should > be flexible enough to prefix a users' home directory (or > --with-rewrite=FILE entry), before the --with-chroot=PATH, so that it > is possible to chroot ~user scripts, into their respective public_html > directories, with a single cgiwrap binary. > > I have reworked your cgiwrap.c and util.c code, to accomodate these > notions, and I am running them on a production webserver. The code > that I inserted looks like crap, right now, but it you're interested > in adding it to the mainstream product, I'll clean up the mess, and > send you my stuff... :) > > Just thought I'd add a little harrassment to your day... :) Oh - and > I finally found where your mailing list archives live, on > sourceforge. You really ought to add a link to the mailing list > archives, to your FAQ, on the website... :) > > > > ---------------------------------------------------------------------- > Join the world?s largest e-mail service with MSN Hotmail. Click Here -- ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 |
|
From: <ch...@lu...> - 2001-12-12 18:12:53
|
I am glad that Annette was able to figure out how to unsubscribe, but I
didnt want my original question to get lost in her misdirected reply.
Sorry for reposting. Thanks in advance for your attention.
-Charles
---------- Forwarded message ----------
Date: Wed, 12 Dec 2001 08:48:48 -0600 (CST)
From: ch...@lu...
To: cgi...@li...
Subject: configuring --with-cgi-dir= with Virtual Hosts
hello all-
i'm in the process of testing cgiwrap for use with hosting client
requiring access to a local cgi-bin. each hosting client has access to a
cgi-bin maintained by the system administrator. i would like to give them
direct access to their own cgi-local directory in which scripts would be
executed against cgiwrap.
i've compiled using:
./configure --with-httpd-user=nobody \
--with-install-dir=/usr/local/bin \
--with-cgi-dir=/j-m/host/<domain>/pub/public_html/cgi-local
the --with-cgi-dir= value is a full path to the hosting client's actual
cgi-local directory. it currently resides in their document root. since
the examples of --with-cgi-dir= seem to be from the perspective of
relative to the user's home dir, i was not certain how to approach this.
the hosting client's directory is not specific to a user account. and
generally individuals maintaining the hosted website through ftp are not
given system accounts.
how should this directive be set up in such a scenario? moreover, i would
prefer to move the cgi-local directory up one physical directory, placing
it within:
/j-m/host/<domain>/pub/
rather than in the actual document root, and then making it available for
web use through an Alias command.
i appreciate your input, and look forward to responses :)
regards, charles
|
|
From: Neulinger, N. <nn...@um...> - 2001-12-12 17:34:01
|
Look at the headers of any message sent to this list, and the link at the bottom of every message that gets sent to the header. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Annette Roach [mailto:ann...@je...] > Sent: Wednesday, December 12, 2001 11:23 AM > To: ch...@lu...; cgi...@li... > Subject: Re: [cgiwrap-users] configuring --with-cgi-dir= with > Virtual Hosts > > > Please help me figure out how to eliminate my name from this > mailing list. > I am on it by accident. > > Thank you for your help. > > A Roach > > ---------- > >From: <ch...@lu...> > >To: <cgi...@li...> > >Subject: [cgiwrap-users] configuring --with-cgi-dir= with > Virtual Hosts > >Date: Wed, Dec 12, 2001, 8:48 AM > > > > > hello all- > > i'm in the process of testing cgiwrap for use with hosting client > > requiring access to a local cgi-bin. each hosting client > has access to a > > cgi-bin maintained by the system administrator. i would > like to give them > > direct access to their own cgi-local directory in which > scripts would be > > executed against cgiwrap. > > > > i've compiled using: > > > > ./configure --with-httpd-user=nobody \ > > --with-install-dir=/usr/local/bin \ > > > --with-cgi-dir=/j-m/host/<domain>/pub/public_html/cgi-local > > > > the --with-cgi-dir= value is a full path to the hosting > client's actual > > cgi-local directory. it currently resides in their document > root. since > > the examples of --with-cgi-dir= seem to be from the perspective of > > relative to the user's home dir, i was not certain how to > approach this. > > the hosting client's directory is not specific to a user > account. and > > generally individuals maintaining the hosted website > through ftp are not > > given system accounts. > > > > how should this directive be set up in such a scenario? > moreover, i would > > prefer to move the cgi-local directory up one physical > directory, placing > > it within: > > > > /j-m/host/<domain>/pub/ > > > > rather than in the actual document root, and then making it > available for > > web use through an Alias command. > > > > i appreciate your input, and look forward to responses :) > > > > regards, charles > > > > > > _______________________________________________ > > cgiwrap-users mailing list > > cgi...@li... > > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > > > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > |
|
From: Annette R. <ann...@je...> - 2001-12-12 17:30:42
|
Please help me figure out how to eliminate my name from this mailing list. I am on it by accident. Thank you for your help. A Roach ---------- >From: <ch...@lu...> >To: <cgi...@li...> >Subject: [cgiwrap-users] configuring --with-cgi-dir= with Virtual Hosts >Date: Wed, Dec 12, 2001, 8:48 AM > > hello all- > i'm in the process of testing cgiwrap for use with hosting client > requiring access to a local cgi-bin. each hosting client has access to a > cgi-bin maintained by the system administrator. i would like to give them > direct access to their own cgi-local directory in which scripts would be > executed against cgiwrap. > > i've compiled using: > > ./configure --with-httpd-user=nobody \ > --with-install-dir=/usr/local/bin \ > --with-cgi-dir=/j-m/host/<domain>/pub/public_html/cgi-local > > the --with-cgi-dir= value is a full path to the hosting client's actual > cgi-local directory. it currently resides in their document root. since > the examples of --with-cgi-dir= seem to be from the perspective of > relative to the user's home dir, i was not certain how to approach this. > the hosting client's directory is not specific to a user account. and > generally individuals maintaining the hosted website through ftp are not > given system accounts. > > how should this directive be set up in such a scenario? moreover, i would > prefer to move the cgi-local directory up one physical directory, placing > it within: > > /j-m/host/<domain>/pub/ > > rather than in the actual document root, and then making it available for > web use through an Alias command. > > i appreciate your input, and look forward to responses :) > > regards, charles > > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > |
|
From: <ch...@lu...> - 2001-12-12 14:48:59
|
hello all-
i'm in the process of testing cgiwrap for use with hosting client
requiring access to a local cgi-bin. each hosting client has access to a
cgi-bin maintained by the system administrator. i would like to give them
direct access to their own cgi-local directory in which scripts would be
executed against cgiwrap.
i've compiled using:
./configure --with-httpd-user=nobody \
--with-install-dir=/usr/local/bin \
--with-cgi-dir=/j-m/host/<domain>/pub/public_html/cgi-local
the --with-cgi-dir= value is a full path to the hosting client's actual
cgi-local directory. it currently resides in their document root. since
the examples of --with-cgi-dir= seem to be from the perspective of
relative to the user's home dir, i was not certain how to approach this.
the hosting client's directory is not specific to a user account. and
generally individuals maintaining the hosted website through ftp are not
given system accounts.
how should this directive be set up in such a scenario? moreover, i would
prefer to move the cgi-local directory up one physical directory, placing
it within:
/j-m/host/<domain>/pub/
rather than in the actual document root, and then making it available for
web use through an Alias command.
i appreciate your input, and look forward to responses :)
regards, charles
|
|
From: Bryan R. <br...@re...> - 2001-12-10 11:49:07
|
Sorry, yes, you're code does check for a valid user in the password file, however, my virtual domain docroots are owned by uid's without a password file entry - so I'll have to disable the check :) Sorry, reading it again, my message wasn't that clear! Bry. On Mon, 10 Dec 2001, Steven Haryanto wrote: > On 09/12/2001 22:50, Bryan Ross wrote: > >If I get your patch up and running, it looks like the only thing I will > >need to change is the small check that you do to make sure that the > >specified UID appears in the password file. > > isn't this already covered in the getpwuid() check? +----- -++- -----+ | Bryan Ross <br...@re...> | +----------------------------------------------------------+ | Calm down -- it's only ones and zeroes.... | +----------------------------------------------------------+ | http://www.return0.net/bryan/ | +----- -++- -----+ |
|
From: Steven H. <st...@ha...> - 2001-12-09 18:44:29
|
On 09/12/2001 22:50, Bryan Ross wrote: >Hi Steven, > >I had a look at your patch, and it does appear to offer a solution to my >problems. A few questions however; > >1/ I've changed my config from rewrite rules over to >use VirtualDocumentRoot. Everything seems to be working okay, apart from >when I run scripts, the 'DOCUMENT_ROOT' environment variable seems to >default to /usr/htdocs. Very strange, seem as though the webserver must be >working out the correct root to run the script in the first place. I >assume this will cause problems with your patch. Any ideas? yes this is normal apache behaviour. i have another patch to apache for this. please take a look at http://steven.haryan.to/apache/ (the proper_docroot patch). >2/ Will your patch work with the latest version of cgiwrap, or do you have >an alternative patch available? i haven't updated my patch. the newer cgiwrap fixes cross-site scripting issue, but since my cgiwrap installations are not vulnerable, i've left them as they are. >3/ More a cgiwrap general question. Does using cgiwrap effect CGI >communication such as get/post method, multipart forms, etc. should not be a problem. with a wrapper, the webserver first invokes the wrapper binary and later if all security checks are ok, the wrapper binary will exec() to the cgi script. so all filehandles are handed over. >If I get your patch up and running, it looks like the only thing I will >need to change is the small check that you do to make sure that the >specified UID appears in the password file. isn't this already covered in the getpwuid() check? >Kind Regards, > >Bryan. -- sh |
|
From: Bryan R. <br...@re...> - 2001-12-09 15:51:05
|
Hi Steven, I had a look at your patch, and it does appear to offer a solution to my problems. A few questions however; 1/ I've changed my config from rewrite rules over to use VirtualDocumentRoot. Everything seems to be working okay, apart from when I run scripts, the 'DOCUMENT_ROOT' environment variable seems to default to /usr/htdocs. Very strange, seem as though the webserver must be working out the correct root to run the script in the first place. I assume this will cause problems with your patch. Any ideas? 2/ Will your patch work with the latest version of cgiwrap, or do you have an alternative patch available? 3/ More a cgiwrap general question. Does using cgiwrap effect CGI communication such as get/post method, multipart forms, etc. If I get your patch up and running, it looks like the only thing I will need to change is the small check that you do to make sure that the specified UID appears in the password file. Kind Regards, Bryan. On Sun, 9 Dec 2001, Steven Haryanto wrote: > i wrote a patch few months back that might be of use: > > http://steven.haryan.to/mod_cgiwrap/cgiwrap-3.6.4-mod_cgiwrap.patch > > i also deploy cgiwrap under a dynamic virtual hosting using > mod_vhost_alias. the patch introduces --with-docroot-owner and > --with-docroot-mode. > > -- > sh > > On 09/12/2001 07:43, Bryan Ross wrote: > >Hi, > > > >Im probably looking for cgiwrap to do something it was never design to > >do... but I thought I would check with the mailinglists before I go > >re-inventing the wheel! > > > >Basically, I've got an apache webserver with loads of virtual domains, > >stored as /www/<domain>/<subdomain>/*. So, http://www.my.com/hello.cgi > >would be found in /www/my.com/www/hello.cgi. > > > >Each virtual domain directory is owned by a unique UID and a common GID, > >with permissions 775. The GID is currently 999 (webadmin), and lets my > >webmasters edit vhost html and cgi files. The UID is just a unique number, > >but doesn't have an associated entry in the password/nis file (ergo, no > >username, homedir, etc). > > > >Further, I use mass dynamically configured virtual domain hosting using > >Apache's rewrite engine. So that means no VirtualHost directives in the > >conf file. By default, all directories have 'Options ExecCGI' > >enabled. Once again, frowned upon by some, but it suits our circumstances. > > > >Now, Im looking to run all cgi requests using some kind of wrapper that > >will do some basic sanity checks, and then drop to setuid to the owner of > >the file - in this case, the unique UID assigned to that client. I plan to > >implement this using Apache's Handler directives. > > > >So... my question is there anyway to configure/patch cgiwrap to just > >setuid the owner of a cgi script without hints from the requested URL. Or > >alternatively, does anyone know of a different wrapper that will handle > >this kind of stuff. > > > >Oh, just to complicate matters, I'll probably want to chroot() cgi > >programs to '/www' aswell - but thats a relatively simple thing to take > >care of. > > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > +----- -++- -----+ | Bryan Ross <br...@re...> | +----------------------------------------------------------+ | Illegitmitatum Non Carborundum Est | +----------------------------------------------------------+ | http://www.return0.net/bryan/ | +----- -++- -----+ |
|
From: Steven H. <st...@ha...> - 2001-12-09 03:45:32
|
i wrote a patch few months back that might be of use: http://steven.haryan.to/mod_cgiwrap/cgiwrap-3.6.4-mod_cgiwrap.patch i also deploy cgiwrap under a dynamic virtual hosting using mod_vhost_alias. the patch introduces --with-docroot-owner and --with-docroot-mode. -- sh On 09/12/2001 07:43, Bryan Ross wrote: >Hi, > >Im probably looking for cgiwrap to do something it was never design to >do... but I thought I would check with the mailinglists before I go >re-inventing the wheel! > >Basically, I've got an apache webserver with loads of virtual domains, >stored as /www/<domain>/<subdomain>/*. So, http://www.my.com/hello.cgi >would be found in /www/my.com/www/hello.cgi. > >Each virtual domain directory is owned by a unique UID and a common GID, >with permissions 775. The GID is currently 999 (webadmin), and lets my >webmasters edit vhost html and cgi files. The UID is just a unique number, >but doesn't have an associated entry in the password/nis file (ergo, no >username, homedir, etc). > >Further, I use mass dynamically configured virtual domain hosting using >Apache's rewrite engine. So that means no VirtualHost directives in the >conf file. By default, all directories have 'Options ExecCGI' >enabled. Once again, frowned upon by some, but it suits our circumstances. > >Now, Im looking to run all cgi requests using some kind of wrapper that >will do some basic sanity checks, and then drop to setuid to the owner of >the file - in this case, the unique UID assigned to that client. I plan to >implement this using Apache's Handler directives. > >So... my question is there anyway to configure/patch cgiwrap to just >setuid the owner of a cgi script without hints from the requested URL. Or >alternatively, does anyone know of a different wrapper that will handle >this kind of stuff. > >Oh, just to complicate matters, I'll probably want to chroot() cgi >programs to '/www' aswell - but thats a relatively simple thing to take >care of. |
|
From: Bryan R. <br...@re...> - 2001-12-09 00:43:47
|
Hi, Im probably looking for cgiwrap to do something it was never design to do... but I thought I would check with the mailinglists before I go re-inventing the wheel! Basically, I've got an apache webserver with loads of virtual domains, stored as /www/<domain>/<subdomain>/*. So, http://www.my.com/hello.cgi would be found in /www/my.com/www/hello.cgi. Each virtual domain directory is owned by a unique UID and a common GID, with permissions 775. The GID is currently 999 (webadmin), and lets my webmasters edit vhost html and cgi files. The UID is just a unique number, but doesn't have an associated entry in the password/nis file (ergo, no username, homedir, etc). Further, I use mass dynamically configured virtual domain hosting using Apache's rewrite engine. So that means no VirtualHost directives in the conf file. By default, all directories have 'Options ExecCGI' enabled. Once again, frowned upon by some, but it suits our circumstances. Now, Im looking to run all cgi requests using some kind of wrapper that will do some basic sanity checks, and then drop to setuid to the owner of the file - in this case, the unique UID assigned to that client. I plan to implement this using Apache's Handler directives. So... my question is there anyway to configure/patch cgiwrap to just setuid the owner of a cgi script without hints from the requested URL. Or alternatively, does anyone know of a different wrapper that will handle this kind of stuff. Oh, just to complicate matters, I'll probably want to chroot() cgi programs to '/www' aswell - but thats a relatively simple thing to take care of. Kind Regards, Bryan. +----- -++- -----+ | Bryan Ross <br...@re...> | +----------------------------------------------------------+ | They say the pen is mightier than the sword. | | (if you miss a deadline, you'd better bring the sword) | +----------------------------------------------------------+ | http://www.return0.net/bryan/ | +----- -++- -----+ |
|
From: Ben L. <be...@wb...> - 2001-12-06 14:01:47
|
Hello, I have a PHP/database-driven website. I'm sure ya'll are familiar with the problem: I need the database password to be kept in an include file readable by the webserver which runs as user nobody--my files therefore have to be readable by the world (I'm on a shared host), exposing my password to everyone else on the system. I develop my website on my home machine (Redhat 7.1, Apache 1.3, PHP 4.0), so I thought I'd install cgiwrap (v3.7.1) on my machine and attempt to get things to work here first (before trying on my hosting provider). So far, I've gotten cgiwrap to work just fine with ordinary cgi scripts. My docroot is /home/ben/www, and the cgi-bin is /home/ben/www/scgi-bin. Now, what I want is for the PHP scripts to be parsed under my userid (instead of "apache") without having to put a shabang at the beginning of each PHP script, and without the scripts having to be put in a special directory. The Phorum (http://www.phorum.org) docs suggest one manner of doing this: <snip doc=security.txt> With apache, it is moderately easy to wrap your php scripts, and you don't even need to change the script extensions. You do, however, need to have a copy of the CGI version of PHP3 available in your cgi-bin directory. You first need to set up an Addtype in the .htaccess file which resides in your Phorum install directory. This setting overrides the default .php setting: AddType application/x-httpd-wphp php And then set up an action for this new type: Action application/x-httpd-wphp /cgi-sys/php-cgiwrap/username/php3.cgi In this case, php-cgiwrap is the wrapper script that your provider has put in place, and it runs the PHP binary with user permissions in the specified user's cgi-bin directory. </snip> I think I get the idea here. Instead of my PHP scripts being the cgi scripts, the PHP binary is, and it knows what to do with my scripts. Sounds good to me, but it didn't work. Here's what the virtualhost section of my httpd.conf file looks like: <VirtualHost 192.168.1.40> DocumentRoot /home/ben/www ServerName ben.log.cabin ServerAlias ben ScriptAlias /scgi-bin/ /var/www/cgi-bin/ <Directory /home/ben/www> AllowOverride All </Directory> </VirtualHost> And here's my .htaccess file in /home/ben/www RemoveType php #Just to get rid of the previous default AddType application/x-httpd-wphp php Action application/x-httpd-wphp /scgi-bin/cgiwrap/ben/php Of course, I put the CGI version of PHP in /home/ben/www/scgi-bin. Then I visit http://ben/index.php, and it dumps the unparsed php script to the client. Replacing cgiwrap with cgiwrapd in the .htaccess file does the same thing. So I thought maybe the "RemoveType php" wasn't doing what I thought it should. I changed the .htaccess file to this: AddType application/x-httpd-wphp pcgi Action application/x-httpd-wphp /scgi-bin/cgiwrap/ben/php Now at least I know cgiwrap is getting called...it gives an Internal Server Error. If I replace cgiwrap with cgiwrapd now, it gives the usual info, but after "Output of script follows:" there's nothing. I don't see any error messages anywhere. The other thing I tried (I don't know much about configuring Apache, so please bear with me :) was changing my .htaccess config file to read: Action test-action /scgi-bin/cgiwrap/ben/php AddHandler test-action .pcgi I get the same results, though. Also, my httpd error logs report [client 192.168.1.40] Premature end of script headers: /var/www/cgi-bin/cgiwrap Sorry this message is lengthy, I just hoped to give enough info to be useful. I'd really appreciate any help you can give. Thanks, Ben Logan -- Ben Logan: ben at wblogan dot net OpenPGP Key KeyID: A1ADD1F0 |
|
From: Tuc <tu...@tt...> - 2001-12-05 03:00:00
|
> > Any time an rlimit is set, it's inherited by any future children. > CGIwrap does not set any limits by default. > But isn't the instantiation of that CGIWRAP momentary, and therefore has no more children? Apache could get away with it when it started, but if CGIWRAP runs, runs the CGI, then both disappear, and the Apache process keeps going. Wouldn't RLIMITS be gone the second the CGIWRAP instantiation was gone? Tuc/TTSG Internet Services, Inc. |
|
From: Nathan N. <nn...@um...> - 2001-12-04 21:01:00
|
It would inherit whatever environment cgiwrap/apache was executed under then. I.e. if you have nproc limited when you run apache, that inherits to children. Similar if you enable any of the rlimit limits with apache modules. Any time an rlimit is set, it's inherited by any future children. CGIwrap does not set any limits by default. -- Nathan Kyle wrote: > > > It's a standard O/S facility. See setrlimit man page on your O/S. > > Um, I can't get that to work in RedHat Linux, Nathan. There is ulimit, > but it is set to 'unlimited' by default, which is how my server is > setup. > > To expand on my original question, I want my server unlimited on the > number of CGIs it can process. I don't care if it slows down to a > snail's pace, I want them ALL to run when called. > > So, by *NOT* including the --with-rlimit-nproc=XX switch, am I allowing > an unlimited number of scripts to be run by CGIWrap? I looked in the > configure.h file, but it just seemed to be undefined, as Tuc pointed > out. I'm hoping undefined = unlimited. :) > > -Kyle > > Nathan Neulinger wrote: > > > > Well, you ran "./configure"... it did exactly what it's supposed to. None > > of those rlimit limit are turned on unless you specfifically request them > > to be turned on. > > > > You need to specify --with-rlimit-nproc or --with-rlimit-nproc=XX > > > > As far as what it does, it simply issues the setrlimit() system call prior > > to executing your script. It's a standard O/S facility. See setrlimit man > > page on your O/S. > > > > -- Nathan > > > > On Mon, Dec 03, 2001 at 06:41:43PM -0500, Tuc wrote: > > > > > > On Mon, Dec 03, 2001 at 05:01:25PM -0500, Tuc wrote: > > > > > > > > > > > > Here's a code snip from the cgiwrap web site: > > > > > > > > > > > > --with-rlimit-nproc=COUNT > > > > > > limit number of processes with setrlimit > > > > > > > > > > > > That seems to be the entire documentation on this setting that I can > > > > > > find. So, what is the default value if I don't specify COUNT? > > > > > > > > > > > UNLIMITED from what I can tell. It **LOOKS** like the doco says > > > > > 32, but I checked configure and it seems to imply unlimited. > > > > > > > > I just looked at configure, and it should be 32. At least that is what > > > > the source of configure.in says for nproc, but I have not tried it. > > > > > > > > > > From "./configure" > > > > > > checking for limit rlimit-cpu... none > > > checking for limit rlimit-vmem... none > > > checking for limit rlimit-as... none > > > checking for limit rlimit-fsize... none > > > checking for limit rlimit-data... none > > > checking for limit rlimit-stack... none > > > checking for limit rlimit-core... none > > > checking for limit rlimit-rss... none > > > checking for limit rlimit-nproc... none > > > checking for limit rlimit-nofile... none > > > checking for limit rlimit-memlock... none > > > > > > > > > from config.h > > > > > > /* #undef CONF_USE_RLIMIT_ANY */ > > > /* #undef CONF_USE_RLIMIT_AS */ > > > /* #undef CONF_USE_RLIMIT_CPU */ > > > /* #undef CONF_USE_RLIMIT_VMEM */ > > > /* #undef CONF_USE_RLIMIT_FSIZE */ > > > /* #undef CONF_USE_RLIMIT_DATA */ > > > /* #undef CONF_USE_RLIMIT_STACK */ > > > /* #undef CONF_USE_RLIMIT_CORE */ > > > /* #undef CONF_USE_RLIMIT_RSS */ > > > /* #undef CONF_USE_RLIMIT_NPROC */ > > > /* #undef CONF_USE_RLIMIT_NOFILE */ > > > /* #undef CONF_USE_RLIMIT_MEMLOCK */ > > > > > > > > > Nathan, can you tell us more what the NPROC actually > > > is all about? > > > > > > Tuc/TTSG Internet Services, Inc. > > > > ------------------------------------------------------------ > > Nathan Neulinger EMail: nn...@um... > > University of Missouri - Rolla Phone: (573) 341-4841 > > Computing Services Fax: (573) 341-4216 > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users |
|
From: Nathan N. <nn...@um...> - 2001-12-04 16:56:42
|
Well, you ran "./configure"... it did exactly what it's supposed to. None of those rlimit limit are turned on unless you specfifically request them to be turned on. You need to specify --with-rlimit-nproc or --with-rlimit-nproc=XX As far as what it does, it simply issues the setrlimit() system call prior to executing your script. It's a standard O/S facility. See setrlimit man page on your O/S. -- Nathan On Mon, Dec 03, 2001 at 06:41:43PM -0500, Tuc wrote: > > > > On Mon, Dec 03, 2001 at 05:01:25PM -0500, Tuc wrote: > > > > > > > > Here's a code snip from the cgiwrap web site: > > > > > > > > --with-rlimit-nproc=COUNT > > > > limit number of processes with setrlimit > > > > > > > > That seems to be the entire documentation on this setting that I can > > > > find. So, what is the default value if I don't specify COUNT? > > > > > > > UNLIMITED from what I can tell. It **LOOKS** like the doco says > > > 32, but I checked configure and it seems to imply unlimited. > > > > I just looked at configure, and it should be 32. At least that is what > > the source of configure.in says for nproc, but I have not tried it. > > > > From "./configure" > > checking for limit rlimit-cpu... none > checking for limit rlimit-vmem... none > checking for limit rlimit-as... none > checking for limit rlimit-fsize... none > checking for limit rlimit-data... none > checking for limit rlimit-stack... none > checking for limit rlimit-core... none > checking for limit rlimit-rss... none > checking for limit rlimit-nproc... none > checking for limit rlimit-nofile... none > checking for limit rlimit-memlock... none > > > from config.h > > /* #undef CONF_USE_RLIMIT_ANY */ > /* #undef CONF_USE_RLIMIT_AS */ > /* #undef CONF_USE_RLIMIT_CPU */ > /* #undef CONF_USE_RLIMIT_VMEM */ > /* #undef CONF_USE_RLIMIT_FSIZE */ > /* #undef CONF_USE_RLIMIT_DATA */ > /* #undef CONF_USE_RLIMIT_STACK */ > /* #undef CONF_USE_RLIMIT_CORE */ > /* #undef CONF_USE_RLIMIT_RSS */ > /* #undef CONF_USE_RLIMIT_NPROC */ > /* #undef CONF_USE_RLIMIT_NOFILE */ > /* #undef CONF_USE_RLIMIT_MEMLOCK */ > > > Nathan, can you tell us more what the NPROC actually > is all about? > > Tuc/TTSG Internet Services, Inc. ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 |
|
From: Nathan N. <nn...@um...> - 2001-12-04 16:56:40
|
On Mon, Dec 03, 2001 at 05:01:25PM -0500, Tuc wrote: > > > > Here's a code snip from the cgiwrap web site: > > > > --with-rlimit-nproc=COUNT > > limit number of processes with setrlimit > > > > That seems to be the entire documentation on this setting that I can > > find. So, what is the default value if I don't specify COUNT? > > > UNLIMITED from what I can tell. It **LOOKS** like the doco says > 32, but I checked configure and it seems to imply unlimited. I just looked at configure, and it should be 32. At least that is what the source of configure.in says for nproc, but I have not tried it. > > Tuc/TTSG Internet Services, Inc. > (I also have this question out, no replies) > > _______________________________________________ > 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 |
2 messages has been excluded from this view by a project administrator.
