cgiwrap-users

[cgiwrap-users] CGIWrap Error: User not found

[Florian W. <wa...@cl...>]

I'm using an apache_1.3.28 with php-4.3.3 as cgi-binary .
I compilied cgiwrap-3.8 with the following configurations.
I think there is something wrong with the extra pathinfo, but I haven't
figured it out yet !
I will apreciate every hint to solve this problem
thanx
florian
-----
./configure --with-check-shell --with-rlimit-core=0 --with-rlimit-cpu=60 \
 --without-redirect-stderr --without-logging-file --with-perl=/usr/bin/perl
\
 --with-httpd-user=apache --with-cgi-dir=/wev/WebSites/cgi-bin \
 --with-install-dir=/web/cgi-bin --with-wall \
 --with-local-contact-email=se...@wa... --with-php=/usr/bin/php \
 --with-php-interpreter
 -----
httpd.conf :
-----------
.
.
.
ScriptAlias /cgi-bin/ "/web/cgi-bin/"
 AddHandler cgi-wrapper .php
 AddHandler cgi-wrapper .cgi
 Action cgi-wrapper /cgi-bin/cgiwrap
.
.
.


CGIWrap Error: User not found



CGIWrap was unable to find the user 'test-php.php' in the password file on
this server.
Check the URL and try again.



Local Information and Documentation:
Server Data:
Server Name: 192.168.0.5
Server Protocol: HTTP/1.1
Virtual Host: 192.168.0.5
Request Data:
User Agent/Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Request Method: GET
Remote Address: 192.168.0.1
Remote Port: 4475
Extra Path Info: /test-php.php
Referring Page: http://192.168.0.5/

[cgiwrap-users] Re: PHP_SELF and cgiwrap issue [FYI]

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

> > > With the enclosed patch you would see PHP setting PHP_SELF correctly.
> > >   1. you configure PHP with
> > > 	--enable-path-info-check
> > >      otherwise you would see no difference.
> > >   2. enable "fixing" path info in php.ini:
> > > 	cgi.fix_pathinfo=1
> 
> Yes, it is fully compatible with older php versions since
> older php cgi sapi did not use PATH_TRANSLATED, but only SCRIPT_FILENAME
> (because of the --enable-discard-path PHP's configuration option).

Although there is no problem with old PHP, there are problems
with Apache, when MultiViews is enabled. I've submitted a bug
to the Apache but I think it would be hard to fix/change:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22618

I've found that PATH_TRANSLATED is wrong if:
   1. MultiViews is enabled for the user directory
2. In the user directory there is any file beginning with the username (e.g. username.css, username.php etc.)
3. In the httpd.conf there is the following configuration:
      AddHandler cgi-wrapper .php  or  AddHandler cgi-wrapper .cgi
      Action cgi-wrapper /cgi-bin/cgiwrap/username

If I call from the browser:
      http://www.virtual.example.com/subdir/script.php
the PATH_TRANSLATED is:
      /user/home/dir/public_html/username.css/subdir/script.php
which is of course WRONG.

... because cgiwrap changes PATH_TRANSLATED to /user/home/dir/public_html/
not to /user/home/dir/public_html/subdir/script.php
... because cgiwrap could not find old PATH_INFO (with username)
in PATH_TRANSLATED, since username is changed to "username.css"

Then php-cgi with cgi.fix_pathinfo=1 could not find script on the disk.
(The PATH_TRANSLATED is wrong set with Apache for every cgiwrap call,
not only for php scripts, but also for cgi scripts.)
NOTE: for cgi scripts it is not a bug, since cgiwrap set
PATH_TRANSLATED to user web-directory+PATH_INFO in all situations.

There are three(+1) possible solutions/workarounds to this problem:
1. disable MultiViews for the PHP scripts, or the whole user directory:
   <LocationMatch "\.(cgi|php|phtml)">
   Options -MultiViews
   </LocationMatch>
2. set cgi.fix_pathinfo=0 in php-cgi.ini or php.ini (PHP_SELF would not be set)
3. Apache would change the httpd behaviour in this particular situation
(3a. do not place username.* files in the user public_html directory. :-)

Best regards,

-- 
Piotr Klaban

Re: [cgiwrap-users] about problem with PATH_TRANSLATED

[Akop P. <ak...@CS...>]

On Mon, Aug 18, 2003 at 08:20:03AM +0200, Piotr Klaban wrote:
> On Sat, Aug 16, 2003 at 03:42:15AM -0700, Akop Pogosian wrote:
> > /cgi-bin/cgiwrap/~user/path/file.cgi
> > 
> > It works, however, PATH_TRANSLATED is set to the system's
> > DOCUMENT_ROOT which is wrong. I am using Apache 2 and cgiwrap 3.8
> 
> I do not know what would be desired behaviour in this situation,
> but why you can not use here:
>   /cgi-bin/cgiwrap/user/path/file.cgi
> without any tilde?
> 
> Regards,
> 
> -- 
> Piotr Klaban

I think it used to work with the tilde before version 3.8. Here is how
we enable PHP and other CGI script execution on our system:

<Directory /services/http/users/*/*/>
    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    AddHandler cgiwrap .cgi .php .php3 .phtml
    Action cgiwrap /cgiwrap/cgiwrap
    <Limit GET POST OPTIONS PROPFIND>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS PROPFIND>
        Order deny,allow
        Deny from all
    </LimitExcept>
    ErrorDocument 500 /cgi-bin/user-errors.cgi
    ErrorDocument 403 /cgi-bin/user-errors.cgi
    ErrorDocument 404 /cgi-bin/user-errors.cgi
</Directory>

So, I am using the AddHandler/Action trick to enable CGI script
execution with cgiwrap and I couldn't find a way to get rid of the
tilde under this setup. I would prefer this method over using the
mod_rewrite because making it work well requires making the httpd.conf
a lot messier and harder to read.


-akop

Re: [cgiwrap-users] about problem with PATH_TRANSLATED

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

On Sat, Aug 16, 2003 at 03:42:15AM -0700, Akop Pogosian wrote:
> /cgi-bin/cgiwrap/~user/path/file.cgi
> 
> It works, however, PATH_TRANSLATED is set to the system's
> DOCUMENT_ROOT which is wrong. I am using Apache 2 and cgiwrap 3.8

I do not know what would be desired behaviour in this situation,
but why you can not use here:
  /cgi-bin/cgiwrap/user/path/file.cgi
without any tilde?

Regards,

-- 
Piotr Klaban

Re: [cgiwrap-users] Feature request and patch

[Akop P. <ak...@CS...>]

I accidentally added in my previous patch changes I didn't want to
submit, in particular, my workaround for the PATH_TRANSLATED problem
mentioned previously. The corrected patch is attached to this message.


-akop

[cgiwrap-users] Feature request and patch

[Akop P. <ak...@CS...>]

One of the apache sites I help manage has chosen for some reason to
keep user's public html directories outside of user home directories.
Each user name maps into a web directory of the following form:

/services/http/users/$1/$u

where $1 is the first letter of the login name and $u is the login
name. Cgiwrap does not have support for such scheme, so we have been
modifying util.c to make this work for a while. However, I thought
recently that it might be a good idea to write a patch for a more
general case and to make it part of cgiwrap so that we don't have to
modify it again and others can benefit from it too. I wrote a patch
that allows to insert the following variables into the user directory
map file:

If $n is found in the directory name where n is an integer less than
or equal to the number of characters in the login name, the $n
variable will be replace with the n'th character to user's login name.
If n is greater than the length of login name, $n is not expanded.

If $u is found in the directory name, the variable is replaced with
user's login name.

Finally, if instead of the user name, you specify the star (*)
character, the current entry will match all users. After applying this
patch, we could use the following entry in the directory map file for
example:

*:/services/http/users/$1/$u

which solved our problem. I have attached my patch to this message as
a proof of concept. The patch format is GNU diff unified format. We
have been using it for weeks with no problems.  If this patch is
rejected, could the cgiwrap developers come up with some other ways of
supporting directory mappings like the one I described?



-akop

[cgiwrap-users] about problem with PATH_TRANSLATED

[Akop P. <ak...@CS...>]

By the way, are there plans to fix the problem with PATH_TRANSLATED in
future versions of cgiwrap? I didn't receive any feedback to my
previous message, that's why I am asking again. I am using the Apache
Actions/AddHandler hack to enable cgiwrap for all users. Under this
setup, for every user CGI file, the handler of this form is invoked:

/cgi-bin/cgiwrap/~user/path/file.cgi

It works, however, PATH_TRANSLATED is set to the system's
DOCUMENT_ROOT which is wrong. I am using Apache 2 and cgiwrap 3.8

-akop

----- Forwarded message from Akop Pogosian <ak...@CS...> -----

From: Akop Pogosian <ak...@CS...>
To: cgi...@li...
Subject: [cgiwrap-users] problem with PATH_TRANSLATED
Date: Sun, 29 Jun 2003 06:54:52 -0700

When testing cgiwrap 3.8, I noticed that PATH_TRANSLATED is being set
to DOCUMENT_ROOT. I think this is happening because of this statement
in SetPathTranslated in util.c:

buf = strstr(new_pt, old_pi);

It doesn't take into account that the user name in old_pi might
contain a tilde in front of it ( e.g. /~user/cgi-bin/test.cgi).
I have copied and pasted the old version of this function for now
since it works fine for my purposes.


-akop

Re: [cgiwrap-users] Re: PHP_SELF and cgiwrap issue

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

On Mon, Aug 11, 2003 at 07:48:14AM -0500, Nathan Neulinger wrote:
> Is this patch backwards compatible with older php versions? 
> 
> If so, you want me to go ahead and apply it to cvs?

> > With the enclosed patch you would see PHP setting PHP_SELF correctly.
> >   1. you configure PHP with
> > 	--enable-path-info-check
> >      otherwise you would see no difference.
> >   2. enable "fixing" path info in php.ini:
> > 	cgi.fix_pathinfo=1

Yes, it is fully compatible with older php versions since
older php cgi sapi did not use PATH_TRANSLATED, but only SCRIPT_FILENAME
(because of the --enable-discard-path PHP's configuration option).

With --enable-path-info-check enabled in PHP 4.3.2 configuration,
and with cgi.fix_pathinfo=1 in php.ini or php-cgi.ini,
the --enable-discard-path is not necessary.

Best regards,

-- 
Piotr Klaban

Re: [cgiwrap-users] Re: PHP_SELF and cgiwrap issue

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

Is this patch backwards compatible with older php versions? 

If so, you want me to go ahead and apply it to cvs?

-- Nathan

On Mon, 2003-08-11 at 05:09, Piotr Klaban wrote:
> On Sat, Aug 02, 2003 at 02:20:46AM -0400, Chris McGuire wrote:
> > I've been researching this issue and noticed that you
> > seem to be out front in trying to get it resolved.
> > 
> > I'm running PHP v4.3.2 as a cgi with cgiwrap v3.8. I've
> > seen it stated that this problem has been fixed, but I'm
> > still having it right now.
> > 
> > Just wondering if you could shed any light on how to get
> > this variable working properly.
> > 
> > Thanks so much for your time. :)
> 
> I am sorry for the late answer, but I am overloaded these days
> and I did not know that PHP changed its PHP_SELF extraction method.
> 
> Now after a few days of tests and thinking, I conclude that
> the cgiwrap program need to change PATH_TRANSLATION content
> for PHP - the script Relative Path should be included in PATH_TRANSLATED:
>    /docroot-directory/scriptRelativePath/pathInfo
> 
> Reason: PHP cgi mode (php-cgi) is for running scripts as an apache's handler,
> just like cgiwrap. It expects PATH_TRANSLATED be in the form of:
>    /real-path-to_directory-called-docroot/script-relative-path[/path-info]
> while it is now:
>    /real-path-to_directory-called-docroot[/path-info]
> 
> Compatibility:
> - I do not use multiuser mode here, then I do not know if it has
>   impact on that
> - old PHP would run scripts as before, with just PHP_SELF equal to PATH_INFO
> - perl scripts and simple cgi scripts would see PATH_TRANSLATED in the old form
>   since PATH_TRANSLATED contains scriptRelativePath only for "interpreted" scripts
> 
> The patch for cgiwrap-3.8 is enclosed to this e-mail.
> With the enclosed patch you would see PHP setting PHP_SELF correctly.
> Apply the patch to the cgiwrap-3.8 sources:
> 
> 	gtar zxvf cgiwrap-3.8.tar.gz
> 	cd cgiwrap-3.8/
> 	patch -p1 < ../cgiwra-3.8.diff
> 	[ ./configure as usual ]
> 	[ make install ]
> 
> NOTE: this fix would work ONLY if:
>   
>   1. you configure PHP with
> 	--enable-path-info-check
>      otherwise you would see no difference.
>   2. enable "fixing" path info in php.ini:
> 	cgi.fix_pathinfo=1
>   3. Remember that PHP 4.3.2 configured as a cgi has two "php" programs
>      - one php-cli and another one php-cgi, both are called
>      php. After compilation you would see:
> 	php-4.3.2/sapi/cgi/php
>         php-4.3.2/sapi/cli/php
>      cgiwrap need to use PHP from cgi SAPI.
>      
>      You can install sapi/cli/php as a /usr/bin/php (or /usr/local/bin/php)
>      and sapi/cgi/php as /usr/bin/php-cgi (or /usr/local/bin/php-cgi)
>      Then configure cgiwrap with:
>         # cd cgiwrap-3.8
>         # ./configure --with-php=/usr/local/bin/php-cgi [... other options]
> 
> If you do not want to test cgi.fix_pathinfo=1 in /etc/php.ini
> you can copy php.ini into the script directory:
>         # cp /etc/php.ini ~user/WWW/php-cgi.ini
> then edit ~user/WWW/php-cgi.ini and enable cgi.fix_pathinfo,
> then test http://address/~user/your_script.php
> 
> Best regards,
-- 

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

[cgiwrap-users] Re: PHP_SELF and cgiwrap issue

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

On Sat, Aug 02, 2003 at 02:20:46AM -0400, Chris McGuire wrote:
> I've been researching this issue and noticed that you
> seem to be out front in trying to get it resolved.
> 
> I'm running PHP v4.3.2 as a cgi with cgiwrap v3.8. I've
> seen it stated that this problem has been fixed, but I'm
> still having it right now.
> 
> Just wondering if you could shed any light on how to get
> this variable working properly.
> 
> Thanks so much for your time. :)

I am sorry for the late answer, but I am overloaded these days
and I did not know that PHP changed its PHP_SELF extraction method.

Now after a few days of tests and thinking, I conclude that
the cgiwrap program need to change PATH_TRANSLATION content
for PHP - the script Relative Path should be included in PATH_TRANSLATED:
   /docroot-directory/scriptRelativePath/pathInfo

Reason: PHP cgi mode (php-cgi) is for running scripts as an apache's handler,
just like cgiwrap. It expects PATH_TRANSLATED be in the form of:
   /real-path-to_directory-called-docroot/script-relative-path[/path-info]
while it is now:
   /real-path-to_directory-called-docroot[/path-info]

Compatibility:
- I do not use multiuser mode here, then I do not know if it has
  impact on that
- old PHP would run scripts as before, with just PHP_SELF equal to PATH_INFO
- perl scripts and simple cgi scripts would see PATH_TRANSLATED in the old form
  since PATH_TRANSLATED contains scriptRelativePath only for "interpreted" scripts

The patch for cgiwrap-3.8 is enclosed to this e-mail.
With the enclosed patch you would see PHP setting PHP_SELF correctly.
Apply the patch to the cgiwrap-3.8 sources:

	gtar zxvf cgiwrap-3.8.tar.gz
	cd cgiwrap-3.8/
	patch -p1 < ../cgiwra-3.8.diff
	[ ./configure as usual ]
	[ make install ]

NOTE: this fix would work ONLY if:
  
  1. you configure PHP with
	--enable-path-info-check
     otherwise you would see no difference.
  2. enable "fixing" path info in php.ini:
	cgi.fix_pathinfo=1
  3. Remember that PHP 4.3.2 configured as a cgi has two "php" programs
     - one php-cli and another one php-cgi, both are called
     php. After compilation you would see:
	php-4.3.2/sapi/cgi/php
        php-4.3.2/sapi/cli/php
     cgiwrap need to use PHP from cgi SAPI.
     
     You can install sapi/cli/php as a /usr/bin/php (or /usr/local/bin/php)
     and sapi/cgi/php as /usr/bin/php-cgi (or /usr/local/bin/php-cgi)
     Then configure cgiwrap with:
        # cd cgiwrap-3.8
        # ./configure --with-php=/usr/local/bin/php-cgi [... other options]

If you do not want to test cgi.fix_pathinfo=1 in /etc/php.ini
you can copy php.ini into the script directory:
        # cp /etc/php.ini ~user/WWW/php-cgi.ini
then edit ~user/WWW/php-cgi.ini and enable cgi.fix_pathinfo,
then test http://address/~user/your_script.php

Best regards,

-- 
Piotr Klaban

Re: [cgiwrap-users] RE: CGIWrap's Lack Of Post Variables

[WSO S. <mai...@ws...>]

Also, you can get a lack of post variables depending on how
you have your php.ini configured. By default newer version of
PHP (CGI Version) have:

register_globals = Off

Depending on how a script is written, it may require this
setting to be On. If that is the case it will appear that the
post variable are being dropped.

The PHP people recommend not to use register_globals = On
anymore and to program using other methods. More info here:

http://www.php.net/manual/en/security.registerglobals.php

Hope this might help somebody out there. It tripped me up
for two days.

-Chris


At 08:43 PM 7/2/2003 -0500, you wrote:
>I'll see about adding them... I really need to get that section of the
>docs produced automatically from configure output so it'll stay current.
>
>-- Nathan
>
>On Wed, 2003-07-02 at 18:33, Renee Gleason wrote:
>> Hi,
>> 
>> I figured out my problem. Its not with cgiwrap. I thought I would let you
>> know what I found since your site is using an older version of PHP
>> (4.2.2).
>> 
>> I am using 4.3.2 and ran across this little *gotcha*. My "Server API" was
>> listed as CLI on the php info, where as yours shows up as "Server API
>> CGI". By default using the -with-apxs=/path/to/apxs installs the CLI
>> binary in [prefix]/bin/php. The CLI was printing out all my scripts as if
>> I had run them from the command line and exactly how it looked using
>> cgiwrapd. I simply removed the -with-apxs line from my php configure line,
>> recompiled and now life is good. The CGI binary was installed and it seems
>> like life is all happy.
>> 
>> This link explains this idea SO MUCH better than I ever could
>> http://php.planetmirror.com/manual/en/features.commandline.php
>> 
>> I hope maybe this will help someone since this looks like its going to
>> stay in PHP and so many people are using PHP.
>> 
>> Thanks again for all your help.
>> 
>> Renee
>> 
>> Any chance that the PHP config flags for cgiwrap will be added to the
>> install web page or mailing list? Thanks again!
>-- 
>
>------------------------------------------------------------
>Nathan Neulinger                       EMail:  nn...@um...
>University of Missouri - Rolla         Phone: (573) 341-4841
>UMR Information Technology             Fax: (573) 341-4216
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] Rewriting of directory indexes / Security implications

[WSO S. <mai...@ws...>]

Well, the alternative is to change source code.

1. I'm not comfortable in my ability to do this correctly.

2. Each time cgiwrap is updated, I'd have to make the change
to the new code. This would complicate upgrades.

3. I'm hosting multiple domains. I'm only using mod_rewrite in
conjunction with cgiwrap for one special "shared secure server"
virtual domain. The other virtual domains just use the normal
AddHandler / Action method.

That being said, if the code change was simple, I'd be willing
to at least try it. I just figured it might not be simple.

Thanks!
-Chris



At 01:04 PM 8/7/2003 +0200, you wrote:
>On Wed, Aug 06, 2003 at 03:58:35PM -0400, WSO Support wrote:
>> No problem... I was just curious. :)
>> 
>> I'm really looking for a way to do it all in mod_rewrite as
>> I have everything else I was trying to accomplish working.
>> 
>> I will be making a post with how I got my rewrite rules
>> to work soon.
>
>why do you want to it with mod_rewrite?
>
>Vriendelijke groeten,
>Frank Louwers
>
>-- 
>Openminds bvba                www.openminds.be
>Tweebruggenstraat 16  -  9000 Gent  -  Belgium

Re[3]: [cgiwrap-users] Rewriting of directory indexes / Security implications

[WSO S. <mai...@ws...>]

No problem... I was just curious. :)

I'm really looking for a way to do it all in mod_rewrite as
I have everything else I was trying to accomplish working.

I will be making a post with how I got my rewrite rules
to work soon.

Thanks,
Chris


At 09:11 PM 8/6/2003 +0200, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hello WSO,
>
>Wednesday, August 6, 2003, 2:56:16 PM, you wrote:
>
>> Thanks for the response... I assume that you are not sharing
>> your wrapper?
>
>
>Well I will. Just give me some time to put it somewhere.
>
>
>Best regards,
> Gabriel
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 6.0.2i
>
>iQEVAwUBPzFEvcZa2WpymlDxAQH87ggAtOtt9PIfsxr3kcR1CBcEkMYzSrmHmj6I
>ZBNmDvTPadCz9XA5dzcnQR3PvKUoGWjInvzZZxyXJYPpwA6mhciRxqOhDqJVjLR9
>Fzu0LlXS7Z4gT2P5oVLeSnS32gDGF6qnEWh0ou+gkdsg3KaA2seb0RgSg7VzCpqa
>MhiGPy+KnLA9iQyohaxCooQLQADbXeRHnFr7Thq+ioQ627Fm9y/nA536P5SSkEMY
>c4z+zxfx1167quDVgykc694A7kuGd3kmHl2kvIduPQc/I8EgekcqcxUttf9TDuTV
>W81R8+qd1L/fT/ncu5k9DcZL2rTW35zQaJljz1n74b53I0Ra2jeV7g==
>=tJNy
>-----END PGP SIGNATURE-----

Re[2]: [cgiwrap-users] Rewriting of directory indexes / Security implications

[WSO S. <mai...@ws...>]

Thanks for the response... I assume that you are not sharing
your wrapper?

So you ended up changing the wrapper code instead of finding a
way to fix it by changing your mod_rewite directives? That stinks.

I wonder if it is possible using just mod_rewite? I'd like to keep
using the stock cgiwrap for compatibility purposes.

Thanks,
Chris



At 10:02 AM 8/6/2003 +0200, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hello WSO,
>
>Wednesday, August 6, 2003, 4:50:44 AM, you wrote:
>
>> Gabriel,
>
>> I'm having the exact same problem where the index page isn't found
>> when using mod_rewrite with cgiwrap.
>
>> In my case there is an index.php in the directory and it
>> isn't being found automatically. It looks for index.cgi by
>> default for some reason.
>
>> Has anybody out there come up with a solution?
>
>I have written my own cgiwrapper by now with which it seems to work...
>
>
>Best regards,
> Gabriel
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 6.0.2i
>
>iQEVAwUBPzCn/MZa2WpymlDxAQGrMgf8DUeTi/pCgiTerwJXwURGt0XC8Q7oxXvG
>ipG3Yh2NA2kp0e70NAuYy56kBGGOUW4gjvob2zAxZyTYIsHBkjVNuJxDVf7cKUwA
>bwTvtlaGbzKJJFn50yP1o1wiGCKojfn2TW1L7Ce40tqTnx7wrU9mj2bChWvcOaMX
>8HFimUCdjAacax+hCsobbLcrx6ANI9nllWChBH8Q8VF+L3HPfnaE/p5SGzz1Apyz
>g7RRincvyrVPEopvC1jcplGosSexHIfzoOGbHX/Fqrut8DIWgrYpsVuGjDYoa/zg
>kfLuWXQEcqXCDlJoKiUKLs8ztBY//ku4qhXg6aBPhSim8/ed4mSyxA==
>=HKAx
>-----END PGP SIGNATURE-----

Re: [cgiwrap-users] Rewriting of directory indexes / Security implications

[WSO S. <mai...@ws...>]

Gabriel,

I'm having the exact same problem where the index page isn't found
when using mod_rewrite with cgiwrap.

In my case there is an index.php in the directory and it
isn't being found automatically. It looks for index.cgi by
default for some reason.

Has anybody out there come up with a solution?

Thanks!
Chris



At 07:18 PM 5/20/2003 +0200, you wrote:
>Hi,
>I'm stumbling over a probably rather easily solved problem with my
>rewrite rules:
>
>RewriteEngine On
>RewriteRule (.*\.php.*) /cgi-sys/cgiwrap/user/$1 [PT,NS,T=application/x-http-cgi]
>RewriteRule (.*\.cgi.*) /cgi-sys/cgiwrap/user/$1 [PT]
>
>works perfectly for anything but the directory index (that is
>index.cgi and index.php in our case, of course index.html still
>works ;-) as cgiwrap doesn't seem to know that it should look for
>index. whatever in case the final element of a path is a directory.
>So now I'm wondering how to rewrite the URL to get that working or
>would I have to patch cgiwrap to do that?
>
>
>Furthermore, is there anything cgiwrap does against the following:
>.htaccess auth required users accessing private/somescript.cgi by
>simply using cgiwrap to execute the script? It's a known problem with
>PHP that if you have it installed in the cgi-bin it might very well
>expose your whole site to everyone who cares to look as it ignores
>.htaccess.
>
>Is .htaccess checked before a rewrite is done? If it were, I could
>simply stop users from directly using cgiwrap and be on the safe side,
>right?
>
>Thanks for any comments,
>Gabriel
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] Rewrite possibility for cgiwrap

[WSO S. <mai...@ws...>]

Thanks for your input Chung. I tried your suggestion but
it didn't work. It is as though the mod_rewrite directives
are being ignored. I commented out the AddHandler for .php
and other cgi's and commented out the Action in the www.secure.com
container. When I call a php script, the script simply prints
to the screen in text. The rewrite rules are either not matching
or just not working.

BTW, I do have RewriteEngine On and RewriteOptions inherit
in the www.secure.com container. So that can be eliminated as
a cause.

Any other suggestions?

Thanks so much! :)

-Chris



Also, I've noticed that we'd have to make sure we only rewrite
the URL if the URL ends in .php, .pl, .cgi, etc. Otherwise
we'd be rewriting regular web pages.



At 12:44 PM 8/4/2003 -0500, you wrote:
>On Sun, 03 Aug 2003 00:42:51 -0400, WSO Support
><mai...@ws...> sent this through the Matrix:
>
><snip>
>> So instead I thought I could drop the ScriptAlias totally
>> and just use a mod_rewite statement for each virtual
>> domain. Yes, this would be inefficient, but it would only
>> be used through the shared secure server, not on a regular
>> basis. So far this is what I have for mod_rewite:
>> 
>> RewriteCond %{REQUEST_URI}    ^www\.domain\.com(.*)$ [nocase]
>> RewriteRule ^/$               https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www$1
>> 
>> BTW, this does NOT work. I'm not very good at mod_rewite.
>> But I think this might work if written properly. Basically
>> what is needed is how to translate:
>> 
>> https://www.secure.com/www.domain.com/page.php
>> 
>> Into:
>> https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/page.php
>
>Hi Chris,
>
>Your regular expression is almost there, you just need to
>leave out the "^". REQUEST_URI starts at the document root
>so in URL above it would be:
>
>        /www.domain.com/page.php
>
>So the revised mod_rewrite line is:
>
>  RewriteCond %{REQUEST_URI}    www\.domain\.com(.*)$
>
>The only problem I can see is that you might get some goofy
>input where "www.domain.com" could appear more than once
>(possibly from someone trying to look for security holes).
>I'd write it like this to avoid this and other potential
>problems:
>
>RewriteCond %{REQUEST_URI} ^/www\.domain\.com/(.*)$ [nocase]
>RewriteRule ^/$ https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/$1
>
>
>Chung
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] Rewrite possibility for cgiwrap

[Chung Y. L. <ga...@ui...>]

On Sun, 03 Aug 2003 00:42:51 -0400, WSO Support
<mai...@ws...> sent this through the Matrix:

<snip>
> So instead I thought I could drop the ScriptAlias totally
> and just use a mod_rewite statement for each virtual
> domain. Yes, this would be inefficient, but it would only
> be used through the shared secure server, not on a regular
> basis. So far this is what I have for mod_rewite:
> 
> RewriteCond %{REQUEST_URI}	^www\.domain\.com(.*)$ [nocase]
> RewriteRule ^/$		https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www$1
> 
> BTW, this does NOT work. I'm not very good at mod_rewite.
> But I think this might work if written properly. Basically
> what is needed is how to translate:
> 
> https://www.secure.com/www.domain.com/page.php
> 
> Into:
> https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/page.php

Hi Chris,

Your regular expression is almost there, you just need to
leave out the "^". REQUEST_URI starts at the document root
so in URL above it would be:

	/www.domain.com/page.php

So the revised mod_rewrite line is:

  RewriteCond %{REQUEST_URI}	www\.domain\.com(.*)$

The only problem I can see is that you might get some goofy
input where "www.domain.com" could appear more than once
(possibly from someone trying to look for security holes).
I'd write it like this to avoid this and other potential
problems:

RewriteCond %{REQUEST_URI} ^/www\.domain\.com/(.*)$ [nocase]
RewriteRule ^/$	https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/$1


Chung

Re: [cgiwrap-users] Rewrite possibility for cgiwrap

[WSO S. <mai...@ws...>]

Nathan,

Thanks so much for your reply. Yes, I do need to give you
more background about what I'm trying to accomplish. It might
be long, but hopefully it will be complete and understandable.

Let me just first say that what I'm trying to do is a little
abnormal. I'm trying to get cgiwrap to work with a "shared secure
server." Let me also tell you how I built cgiwrap and php.

CGIWrap:
./configure \
--with-check-shell \
--with-rlimit-core=0 \
--with-rlimit-cpu=120 \
--without-redirect-stderr \
--with-logging-file=/var/log/cgiwrap.log \
--with-perl=/usr/bin/perl \
--with-httpd-user=nobody \
--with-httpd-group=nogroup \
--with-deny-file=/etc/cgiwrap.deny \
--with-cgi-dir=. \
--without-check-owner \
--without-check-symlink \
--with-install-dir=/usr/local/apache/cgi-bin \
--with-install-group=wheel \
--with-wall \
--with-php=/usr/local/bin/php \
--with-php-interpreter

PHP:
./configure \
--with-mysql=/usr/local \
--with-config-file-path=/etc \
--enable-discard-path \
--enable-ftp \
--enable-trans-sid \
--with-gd \
--with-zlib-dir=/usr/local \
--with-ttf=/usr/local/ \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local \
--enable-xslt \
--with-xslt-sablot

I simply create a symbolic link from the document root of
the secure server domain into each virtual domain document
root. I name the symlink the same as the domain I'm linking
into for simplicity. This allows a user to call their pages
"through" the secure server without having to buy their own cert.

For example:

Unsecure:
URL: http://www.domain.com/page.htm
Real Path: /usr/home/username/www.domain.com/www/page.htm

Secure:
URL: https://www.secure.com/www.domain.com/page.htm
Real Path: /usr/home/secureuser/www.secure.com/www/www.domain.com/page.htm

"www.domain.com" is the actual name of the symlink to /usr/home/username/www.domain.com/www

Hope that isn't too confusing. It works very well, quite slick.

But not so great when you are trying to call a script
securely through cgiwrap using this method.

What happens is that the script ends up running under the
userid of the user who is assigned to the www.secure.com
account, 'secureuser' in my examples.

Just to be clear, I am using the handler method with
ScriptAlias in the <VIRTUALHOST> container, like this:

Action cgi-wrapper /cgi-bin/cgiwrap/secureuser/www.secure.com/www

Now, I can force cgiwrap to go through the shared secure
server AND still run under the correct userid by skipping
the Apache handler and using the long style URL, like this.

https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/page.php


But this is cumbersome and frankly, it is so hard to explain
to customers that it almost isn't worth it.

This same script called unsecurly would simply be:
http://www.domain.com/page.php

I'd like to keep it that simple when going through the shared
secure server. If called like this...

http://www.secure.com/www.domain.com/page.php

...the script will run fine, but it runs as 'secureuser' and
not as the owner of the script. This essentially defeats the
purpose of running it through cgiwrap at all. Remember, in the
URL above 'www.domain.com' is a symlink to the document root
of the domain of the same name.

Please keep in mind, when you take the shared secure server
thing out of the equation, everything works great! So, the
setup is fine.

Now, getting to my original question. My thought was to
dynamically rewrite the ScriptAlias line within the
www.secure.com VIRTUALHOST container so that it inserted the
username of the owner of the script that was being called at
the time. Then I could successfully get the script to go
through the shared secure server, run under the userid of
the script owner and be able to use the short handler style URL.

Turns out changing the ScriptAlias line will not accomplish
the goal. I'm not really sure why, but if I manually change
the ScritpAlias in www.secure.com to be the following...

Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www

...it doesn't work. I get the following error when calling
a script like this http://www.secure.com/www.domain.com/page.php.
The error is:

Execution of (www.domain.com/www) is not permitted for the following reason:
Script is not a regular file

I don't know why it isn't reaching the file. Looks like the page.php
part is getting dropped.

So instead I thought I could drop the ScriptAlias totally and
just use a mod_rewite statement for each virtual domain. Yes,
this would be inefficient, but it would only be used through
the shared secure server, not on a regular basis. So far this
is what I have for mod_rewite:

RewriteCond %{REQUEST_URI}     ^www\.domain\.com(.*)$ [nocase]
RewriteRule ^/$                https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www$1

BTW, this does NOT work. I'm not very good at mod_rewite. But
I think this might work if written properly. Basically what is
needed is how to translate:

https://www.secure.com/www.domain.com/page.php

Into:
https://www.secure.com/cgi-bin/cgiwrap/username/www.domain.com/www/page.php

Yes, I do know that simply buying a secure cert for www.domain.com
would solve this whole issue (at least for that domain). And yes,
scripts located under the www.secure.com domain work fine called
securely like this, for example, https://www.secure.com/page,php

Whew... I hope that is clear. I would simply love to flesh
out any questions or confusion you might have. I'd really like
another set of eyes to look at my ideas here and maybe
come up with a solution.

If you've read this whole thing, thanks for taking the time.

-Chris




At 02:37 PM 8/2/2003 -0500, you wrote:
>Any particular reason you don't just rewrite internally to the standard
>cgiwrap syntax in a common cgi-bin dir?
>
>Combining that with the CGIWRAP_REQUIRE_USER functionality in current
>versions of cgiwrap should allow you to expose a /cgi-bin containing
>cgiwrap without it being usable by direct url and only rewrite.
>
>I guess I'd need a bit more info about what you're trying to accomplish
>and what objections there are to exposing standard access paths.
>
>-- Nathan
>
>On Sat, 2003-08-02 at 11:30, WSO Support wrote:
>> I've researched this a little more and here's my progress. Any
>> additional help would appreciated.
>> 
>> Using Apache 1.3.27 on a FreeBSD machine with mod_rewrite enabled.
>> 
>> In my Apache <VIRTUALHOST> containers I have lines like this to allow
>> easy execution of cgi's that cgiwrap is configured to handle:
>> 
>> Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www
>> 
>> Don't worry too much about the example, it is just for reference
>> purposes.
>> 
>> I would love to be able to use some kind of mod_rewrite rule to
>> dynamically replace the 'username' part of the example above with the
>> real owner of the script cgiwrap is going to execute.
>> 
>> I think I may be able to do this by extracting the username that would
>> show up in the REQUEST_FILENAME variable. For example, the full path
>> to the requested file might be something like:
>> 
>> /usr/home/username/www.domain.com/www/filename.cgi
>> 
>> If I could pluck the 'username' out and insert it dynamically into the
>> Action line example above, that would do the trick.
>> 
>> Maybe somebody has tried this and could offer some suggestions.
>> 
>> If somebody can do this, I will *pay* them. :)
>> 
>> Thanks,
>> Chris
>> 
>> 
>> At 11:17 PM 8/1/2003 -0400, you wrote:
>> >Hi all,
>> >
>> >In my Apache <VIRTUALHOST> containers I have lines like this
>> >to allow easy execution of cgi's that cgiwrap is configured to
>> >handle:
>> >
>> >Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www
>> >
>> >I would love to be able to use some kind of mod_rewrite rule to
>> >dynamically replace the 'username' part of this line with the
>> >real owner of the script cgiwrap is going to execute.
>> >
>> >Is it possible for mod_rewrite to know the owner of the script
>> >at this point?
>> >
>> >I apologize, this looks more like a mod_rewrite question, but maybe
>> >somebody has tried this and could offer some suggestions.
>> >
>> >Thank you
>> >Chris
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> >Data Reports, E-commerce, Portals, and Forums are available now.
>> >Download today and enter to win an XBOX or Visual Studio .NET.
>> >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>> >_______________________________________________
>> >cgiwrap-users mailing list
>> >cgi...@li...
>> >https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>> _______________________________________________
>> cgiwrap-users mailing list
>> cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>-- 
>
>------------------------------------------------------------
>Nathan Neulinger                       EMail:  nn...@um...
>University of Missouri - Rolla         Phone: (573) 341-4841
>UMR Information Technology             Fax: (573) 341-4216
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

Re: [cgiwrap-users] Rewrite possibility for cgiwrap

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

Any particular reason you don't just rewrite internally to the standard
cgiwrap syntax in a common cgi-bin dir?

Combining that with the CGIWRAP_REQUIRE_USER functionality in current
versions of cgiwrap should allow you to expose a /cgi-bin containing
cgiwrap without it being usable by direct url and only rewrite.

I guess I'd need a bit more info about what you're trying to accomplish
and what objections there are to exposing standard access paths.

-- Nathan

On Sat, 2003-08-02 at 11:30, WSO Support wrote:
> I've researched this a little more and here's my progress. Any
> additional help would appreciated.
> 
> Using Apache 1.3.27 on a FreeBSD machine with mod_rewrite enabled.
> 
> In my Apache <VIRTUALHOST> containers I have lines like this to allow
> easy execution of cgi's that cgiwrap is configured to handle:
> 
> Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www
> 
> Don't worry too much about the example, it is just for reference
> purposes.
> 
> I would love to be able to use some kind of mod_rewrite rule to
> dynamically replace the 'username' part of the example above with the
> real owner of the script cgiwrap is going to execute.
> 
> I think I may be able to do this by extracting the username that would
> show up in the REQUEST_FILENAME variable. For example, the full path
> to the requested file might be something like:
> 
> /usr/home/username/www.domain.com/www/filename.cgi
> 
> If I could pluck the 'username' out and insert it dynamically into the
> Action line example above, that would do the trick.
> 
> Maybe somebody has tried this and could offer some suggestions.
> 
> If somebody can do this, I will *pay* them. :)
> 
> Thanks,
> Chris
> 
> 
> At 11:17 PM 8/1/2003 -0400, you wrote:
> >Hi all,
> >
> >In my Apache <VIRTUALHOST> containers I have lines like this
> >to allow easy execution of cgi's that cgiwrap is configured to
> >handle:
> >
> >Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www
> >
> >I would love to be able to use some kind of mod_rewrite rule to
> >dynamically replace the 'username' part of this line with the
> >real owner of the script cgiwrap is going to execute.
> >
> >Is it possible for mod_rewrite to know the owner of the script
> >at this point?
> >
> >I apologize, this looks more like a mod_rewrite question, but maybe
> >somebody has tried this and could offer some suggestions.
> >
> >Thank you
> >Chris
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
> >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >_______________________________________________
> >cgiwrap-users mailing list
> >cgi...@li...
> >https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
-- 

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

Re: [cgiwrap-users] Rewrite possibility for cgiwrap

[WSO S. <mai...@ws...>]

I've researched this a little more and here's my progress. Any
additional help would appreciated.

Using Apache 1.3.27 on a FreeBSD machine with mod_rewrite enabled.

In my Apache <VIRTUALHOST> containers I have lines like this to allow
easy execution of cgi's that cgiwrap is configured to handle:

Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www

Don't worry too much about the example, it is just for reference
purposes.

I would love to be able to use some kind of mod_rewrite rule to
dynamically replace the 'username' part of the example above with the
real owner of the script cgiwrap is going to execute.

I think I may be able to do this by extracting the username that would
show up in the REQUEST_FILENAME variable. For example, the full path
to the requested file might be something like:

/usr/home/username/www.domain.com/www/filename.cgi

If I could pluck the 'username' out and insert it dynamically into the
Action line example above, that would do the trick.

Maybe somebody has tried this and could offer some suggestions.

If somebody can do this, I will *pay* them. :)

Thanks,
Chris


At 11:17 PM 8/1/2003 -0400, you wrote:
>Hi all,
>
>In my Apache <VIRTUALHOST> containers I have lines like this
>to allow easy execution of cgi's that cgiwrap is configured to
>handle:
>
>Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www
>
>I would love to be able to use some kind of mod_rewrite rule to
>dynamically replace the 'username' part of this line with the
>real owner of the script cgiwrap is going to execute.
>
>Is it possible for mod_rewrite to know the owner of the script
>at this point?
>
>I apologize, this looks more like a mod_rewrite question, but maybe
>somebody has tried this and could offer some suggestions.
>
>Thank you
>Chris
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users

[cgiwrap-users] Rewrite possibility for cgiwrap

[WSO S. <mai...@ws...>]

Hi all,

In my Apache <VIRTUALHOST> containers I have lines like this
to allow easy execution of cgi's that cgiwrap is configured to
handle:

Action cgi-wrapper /cgi-bin/cgiwrap/username/www.domain.com/www

I would love to be able to use some kind of mod_rewrite rule to
dynamically replace the 'username' part of this line with the
real owner of the script cgiwrap is going to execute.

Is it possible for mod_rewrite to know the owner of the script
at this point?

I apologize, this looks more like a mod_rewrite question, but maybe
somebody has tried this and could offer some suggestions.

Thank you
Chris

[cgiwrap-users] Kerberos 5 / AFS authentication patch

[Mark M. <mar...@um...>]

I've created a patch for CGIwrap 3.8 that enables CGIwrap to get
Kerberos 5 tickets and AFS tokens on a per-user basis on behalf of
the CGIs that it runs.  Documentation on what this patch does and
how to use it is at the end of this message.  The patch itself and
more information are available from

        http://unix.lsa.umich.edu/cgiwrap/

I'm looking for advanced admins to be early testers and provide
feedback.  Right now, the patch works for me in my environment but
that's about all I'm willing to guarantee about it.  I don't know
of any problems with the patch at the current time, but I expect
that a number of problems will be discovered as people try to use
this patch in their own environments, and it may take a while to
find and fix them all.

If you have any questions or feedback, please let me know.

                Mark Montague
                LS&A Information Technology
                The University of Michigan
                mar...@um...

------------------------------------------------------------------------------


                      CGIwrap - Usage with Kerberos 5
     _________________________________________________________________

   Ideally, a CGI script would acquire and manage any credentials it
   needs in order to run. But there are several scenarios in which it is
   beneficial to have CGIwrap manage Kerberos credentials on behalf of
   the CGI scripts which run under it:

     * The user who installed the CGI may not be the CGI's author and may
       prefer (or lack the skills) to modify it, and the CGI's author may
       not have anticipated the need for the CGI to run in a Kerberos
       environment. If the CGI is a binary (particularly a commercial
       application) it may not be possible to modify it to add Kerberos
       support.
     * The user who wrote and installed the CGI may not be aware of the
       larger web server environment in which their CGI runs and may want
       it to "just work" with other infrastructure services. This allows
       the author to focus on the purpose of the CGI script and avoid
       having to deal with what they consider to be unrelated details. An
       example of users in this category are University faculty.

   CGIwrap can therefore be configured to obtain and manage Kerberos 5
   credentials on behalf of the users who own the CGIs. Credentials are
   obtained and managed separately for each user. Credentials are saved
   between CGI invocations and, when necessary, automatically renewed.
   This means that once credentials have been obtained for a user, other
   scripts owned by that user can re-use the without having to contact
   the Kerberos server each time.

   IMPORTANT NOTE: CGIwrap has been tested with MIT Kerberos version
   1.2.5. CGIwrap will probably not work with non-MIT Kerberos
   distributions.

  Configuring CGIwrap for Kerberos 5

   To enable Kerberos 5 support in CGIwrap, give the --with-krb5 option
   to the configure script when building CGIwrap. configure will try to
   find the krb5-config script that comes with MIT Kerberos versions
   1.2.3 and later, and it will use this script to determine the
   appropriate compilation and linking flags for Kerberos. You can
   override the location of this script by using the --with-krb5-config
   option.

   In order to obtain Kerberos credentials for users, CGIwrap needs a
   keytab for each user. (A keytab is a file containing keys -- binary
   passwords -- for a user). By default, keytabs for all users are stored
   in the directory /usr/adm/cgiwrap-keytabs although this can be
   overridden using the --with-krb5-keytab-dir option. If you want to
   have the same user get different credentials depending upon which
   virtual host the CGI is being run under, use the
   --with-vhost-krb5-keytab-dir option -- in this case, CGIwrap will
   first read any global keytab for the user from krb5-keytab-dir and
   then look in vhost-krb5-keytab-dir for a subdirectory whose name is
   the all-lowercase value of the HTTP_HOST environment variable (or, if
   the --with-vhost-override option was given, it will look in the
   subdirectory whose name is the all-lowercase value of the
   CGIWRAP_AUTH_VHOST environment variable). Both global and
   vhost-specific keytabs will be read, but keys in vhost-specific
   keytabs will be tried first before keys from the global keytab.

   The keytab directories need to be created manually. They must be owned
   by root and must not be writable by any user other than root. Since
   Kerberos keys are functionally equivalent to passwords, it is strongly
   recommended that the keytab directories also be restricted so that
   they can only be read by root. (Note that there will only be a single
   keytab directory unless you specified --with-vhost-krb5-keytab-dir).
   If you have configured CGIwrap to use its chroot facility, the keytab
   directories must be outside the chroot area.

   CGIwrap will cache any Kerberos credentials (ticket) that it obtains
   so that it can re-use them on subsequent invocations, thus avoiding
   the need to contact the Kerberos server each time a CGI is executed.
   By default, these credentials caches are stored in the directory /tmp
   although this can be changed using the --with-krb5-ccache-dir option.
   For increased security, it is highly recommended that you specify
   another directory (such as /ticket) that will only be used for storing
   Kerberos credentials caches (the only reason /tmp is the default is
   because this is where most users and applications expect to find
   Kerberos credentials caches). To enable each virtual host to have its
   own credentials cache directory, use the --with-vhost-krb5-ccache-dir
   option; credentials caches will then be stored in the subdirectory
   whose name is the all-lowercase value of the HTTP_HOST environment
   variable (or, if the --with-vhost-override option was given, it will
   look in the subdirectory whose name is the all-lowercase value of the
   CGIWRAP_AUTH_VHOST environment variable). If
   --with-vhost-krb5-ccache-dir is given, then the "global" directory
   specified with --with-krb5-ccache-dir will never be used.

   The credentials cache directories must be manually created unless they
   already exist on the web server. They must be owned by root, and
   writable by all users for whom CGIwrap will be obtaining Kerberos
   credentials. The Unix "sticky bit" must be set on the credentials
   cache directories in order to prevent the credentials cache files from
   being tampered with by other users. Unix directory permissions of 1733
   are recommended. For further security, consider making the credentials
   cache directories reside on a memory based filesystem. If you have
   configured CGIwrap to use its chroot facility, the credentials cache
   directories must be inside the chroot area; this means that each user
   will effectively have their own credentials cache directory.

   When CGIwrap runs for a particular user, it examines all cached
   credentials and will renew any which have already expired or are about
   to expire. By default, any credential that has expired or will expire
   within the next 1800 seconds (1/2 hour) will be renewed. This can be
   changed using the --with-ticket-renewal-window option.

   When CGIwrap obtains credentials, it will by default request that they
   have a lifetime of 2592000 seconds (1 month). This, in effect, causes
   the ticket to be issued with the maximum lifetime permitted by the
   principal in the Kerberos database for which the ticket was requested
   (see below) or the maximum lifetime permitted by the Kerberos realm
   itself, whichever is less. This behavior can be changed using the
   -with-ticket-max-lifetime option.

    Example:

   At the University of Michigan, CGIwrap is built with the following
   options:

    --with-krb5
    --with-krb5-keytab-dir="/opt/www/etc/cgiwrap-keytabs"
    --with-krb5-ccache-dir="/ticket"

   After building CGIwrap, the system administrator manually runs the
   following commands:

    # mkdir /opt/www/etc/cgiwrap-keytabs
    # chown root:other /opt/www/etc/cgiwrap-keytabs
    # chmod 700 /opt/www/etc/cgiwrap-keytabs

    # mkdir /ticket
    # chown root:other /ticket
    # chmod 1733 /ticket

  Per-user Kerberos 5 configuration

   If no keytab exists for a user, CGIwrap will not try to obtain any
   Kerberos credentials, although it will make available any credentials
   available to the CGI which have been manually obtained and placed in
   the user's credentials cache. Usually, though, you will need to create
   a keytab for each user who will be running CGIs that need Kerberos
   credentials. If you are not a Kerberos administrator, you can have
   your realm's Kerberos administrator create the keytabs for you and you
   can then simply copy them to your web server machine.

   You can have multiple keys in a user's keytab. When CGIwrap runs a CGI
   owned by the user, it will attempt to obtain a Kerberos ticket for
   each entry listed in the keytab. Not all keys in the keytab have to be
   for the same principal.

   The act of adding an entry to a keytab changes the password for the
   principal (user) involved. Therefore, if you want to configure CGIwrap
   to obtain Kerberos credentials for CGIs owned by a user with the user
   name "joe", you would not create the keytab for "joe" -- if you did,
   the user would no longer be able to authenticate using the password
   they set. Instead, create a new principal: "joe/www", "joe/cgiwrap",
   "joe/example.web.server.name" or even "j1234" -- CGIwrap makes no
   assumptions about the names.

   Once the keytab is created, copy it to the correct keytab directory or
   directories. The keytab must be owned by the user or by root, and must
   be readable only by the user and/or root. The name of the keytab file
   must be krb5.keytab.USERNAME (for example, "krb5.keytab.joe").

   Depending on what the CGIs that use the tickets acquired by CGIwrap
   do, you may need to create resources or assign rights to each
   principal listed in the keytab. For example, assume the user "joe" has
   a CGI that searches a shared Cyrus IMAP mailbox for any email messages
   whose subject line begins with the string "URGENT:" that have not been
   responded to and displays these messages on a web page. The keytab for
   user "joe" contains an entry for "joe/ww...@EX...ALM". You
   would need to use the Cyrus IMAP cyradm utility to grant the user
   "joe/www" read access to the shared mailbox (even though "joe" may
   already have access).

   No action needs to be taken with regards to a credentials cache for
   the user; it will be automatically created by CGIwrap.

    Example:

   At the University of Michigan, the following commands are used to do
   the per-user Kerberos 5 set up for CGIwrap users. This example is for
   user "joe" in the Kerberos realm LSA.UMICH.EDU:

    # kadmin -p admmark/admin
    Authenticating as principal admmark/admin with password.
    Enter password:
    kadmin:  addprinc -randkey joe/www
    WARNING: no policy specified for joe/ww...@LS...;
      defaulting to no policy
    Principal "joe/ww...@LS..." created.
    kadmin:  ktadd -k /opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe joe/www
    Entry for principal joe/www with kvno 3, encryption type DES cbc mode with
    CRC-32 added to keytab WRFILE:/opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe.
    kadmin:  quit

   The following commands can be used to verify that everything is okay
   and that CGIwrap will be able to use the keytab successfully. ("5678"
   below is is joe's numerical user id from the /etc/passwd file, LDAP,
   or NIS+).

    # ls -l /opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe
    -rw-------   1 root     other         54 Jul 31 09:10 /opt/www/etc/cgiwrap-
keytabs/krb5.keytab.joe
    # klist -k /opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe
    Keytab name: FILE:/opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe
    KVNO Principal
    ---- --------------------------------------------------------------------
       3 joe/ww...@LS...
    # kinit -5 -k -t /opt/www/etc/cgiwrap-keytabs/krb5.keytab.joe -c /ticket/kr
b5cc_test_5678 joe/www
    # klist /ticket/krb5cc_test_5678
    Ticket cache: FILE:/ticket/krb5cc_test_5678
    Default principal: joe/ww...@LS...

    Valid starting     Expires            Service principal
    07/31/03 09:22:17  07/31/03 19:22:20  krbtgt/LSA...@LS...
    # rm /ticket/krb5cc_test_5678

   Now when one of joe's CGIs is run, CGIwrap will obtain a Kerberos 5
   ticket granting ticket for it for joe/www in the LSA.UMICH.EDU realm.


------------------------------------------------------------------------------


                          CGIwrap - Usage with AFS
     _________________________________________________________________

   CGIwrap will work out of the box with AFS, with at least the following
   directory permissions:

                       Dir        User/Group   Permissions
                  ~             system:anyuser      l
                  ~/public_html system:anyuser      l
                  ~/public_html system:anyuser     rl

   If you are running httpd authenticated as an AFS userid, you can
   replace system:anyuser above with that userid.

  Process authentication group support

   If you are using CGIwrap with AFS I'd suggest making sure to enable
   the AFS support in the configure script (--with-afs). This
   automatically creates a PAG for any script that is launched, that way
   if the script klogs, it won't affect the server or other scripts. When
   using cgiwrap with AFS based accounts, you need to keep in mind that
   scripts are run un-authenticated. This means that any files that are
   accessed will be accessed as system:anyuser. In general, this means
   that the script will not have write access to your directory. See
   below for information on how to have CGIwrap acquire AFS tokens on
   behalf of the user who owns the script.

  AFS authentication support

   The reasons to have CGIwrap authenticate to AFS for scripts rather
   than requiring scripts to authenticate to AFS themselves are the same
   as the reasons for having CGIwrap authenticate to Kerberos 5. See Use
   of CGIwrap with Kerberos 5.

   IMPORTANT NOTE: Currently, in order to have CGIwrap authenticate to
   AFS, you need to be running your AFS cell from a Kerberos 5 realm. The
   Kerberos 5 KDC machine(s) must also be running krb524d. It is not
   currently possible for CGIwrap to authenticate to AFS if you are using
   Kerberos 4 and/or the AFS kaserver, and since OpenAFS is moving
   towards native Kerberos 5 support, it is unlikely that this
   functionality will be added to CGIwrap. If you are running AFS but not
   Kerberos 5, please take a look at the AFS Kerberos 5 Migration Kit.

   ANOTHER IMPORTANT NOTE: Currently, AFS authentication support in CGI
   wrap requires you to use a relatively recent version of the OpenAFS
   client libraries. This code has been tested with OpenAFS 1.2.9.

    Configuring CGIwrap for AFS authentication

   Before configuring CGIwrap for use with AFS, you must first configure
   CGIwrap for use with Kerberos 5. See Use of CGIwrap with Kerberos 5
   for instructions on how to do this.

   Build CGIwrap with the "--with-afs --with-afs-auth" options.

   CGIwrap will attempt to get Kerberos 5 ticket granting tickets for
   each key in the user's keytab file. It will then attempt to use each
   ticket granting ticket to acquire an AFS service ticket for the cell
   with the same realm name contained the ticket granting ticket instance
   (and it will later convert these Kerberos 5 AFS service tickets into
   AFS tokens). For simple AFS cell and Kerberos realm configurations,
   this strategy is adequate. For more complex situations involving
   multiple AFS cells using a single Kerberos realm for authentication,
   or situations where there are multiple Kerberos realms with
   cross-realm trust relationships, CGIwrap needs more information on
   what AFS cells to authenticate to. It uses the ~/.cgiwrap-afs-auth
   file for this purpose. This file contains a list of AFS users, one per
   line, for whom CGIwrap should attempt to acquire tokens. White space
   is ignored and comments are indicated with a pound sign ('#'). For
   example,

    joe.www@some.example.cell     # Get a token for joe.www in this cell...
    joe.www@another.example.cell  # ...as well as for this one.

   The --with-afs-auth-file option can be used to specify another
   location for this file, relative to the user's home directory.
   --with-afs-auth-file="Public/.cell_info" would cause CGIwrap to look
   in the file ~/Public/.cell_info for each user to determine what AFS
   cells to authenticate to.

    Per-user configuration for AFS authentication

   In order to set up AFS authentication for a user, you must first set
   up Kerberos 5 authentication for the user under CGIwrap. See Use of
   CGIwrap with Kerberos 5 for instructions on how to do this.

   Use the "pts createuser" command to ensure that the user exists in the
   AFS PTS database. Replace the slash that separates the user and
   instance name in the Kerberos 5 principal with a period. For example,
   if the Kerberos 5 keytab contains an key for "joe/www" then you would
   run "pts createuser joe.www".

   Create an AFS authentication file, if necessary (see above). This file
   is only necessary when CGIwrap cannot figure out the what tokens to
   get on its own.

   Set AFS ACLs. The ACLs should be the same as in the table above,
   except that the cgi-bin directory needs to be readable by the web
   server both before and after it obtains the user's AFS tokens. In
   addition, specific rights can be granted to the AFS user for whom
   CGIwrap obtained tokens in order to control what the CGI scripts
   can/cannot do. For example, for a guest book CGI, the guest book might
   store its database in the directory ~/guest-db. This directory could
   then be set up with the following ACLs:

    joe rlidwka
    joe.www rli
    system:anyuser none

   ...thus giving the user full access to the directory, allowing the CGI
   to read files from the directory and add new files but not change or
   delete any existing file, and keeping the directory contents private
   from everyone else.


------------------------------------------------------------------------------

[cgiwrap-users] question about chroot and changing directory

[saturne <sa...@ka...>]

hi

i found my problem

so, i chroot in /home/user and html'files are in /home/www and cgi script in
cgi-bin/

Logging Request (File)
Attempting to chroot:  '/home/domain.com/'

UIDs/GIDs Changed To:
   RUID: '7067'
   EUID: '7067'
   RGID: '100'
   EGID: '100'

Changing current directory to '/home/domain.com/www/cgi-bin'


when cgiwrap change current directory, and because cgiwrap chrooted in
/home/user/, i must have /home/user/home/user/www/cgi-bin instead of
/home/user/www/cgi-bin/

it is possible to tell cgiwrap changing current directory to '/www/cgi-bin'
only? because it's not very funnt to have this path

thanks

[cgiwrap-users] problem with chroot

[saturne <sa...@ka...>]

hi

i'm sorry to write again about this problem, but i can't find any help about
this problem..

so if there is a lot of configuration about apache, i want to know few
things to try resolv my problem..
i can't do anything without it and i don't understand what is my problem...


so, i've one disk, and only partition hda1. users are in /home/user, i
chroot users in /home/user
and cp -Rl /etc /home/user/etc, mount proc, MAKEDEV generic..

first:
i chroot in / (so no really chroot)
in httpd i have ScriptAlias /cgi-bin/ (or cgi-sys) /home/user/www/cgi-bin/

all scripts work fine

second:
i chroot in /home/user
A-in httpd i keep /cgi-bin/ /home/user/www/cgi-bin/
so i have the error cannot chdir ()
B- so in httpd, i put ScriptAlias /cgi-bin/ /www/cgi-bin/ (or /cgi-bin/
www/cgi-bin/)
and i have no cgiwrap'error, because he search the script in
/cgi-bin/cgiwrap/user/cgi-bin/cgiwrap/user/cgi-bin......../script.cgi


Please help me, it's so important for me.. or if you have not any time, give
me a httpd'conf and cgiwrap configure to help me

cgiwrap configure:

./configure --with-perl=/usr/bin/perl \
            --with-local-contact-email=root@$user \
            --with-local-site-url=http://www.$user \
            --with-install-group=users \
            --with-install-dir=/home/$user/www/cgi-sys/ \
            --with-cgi-dir=www/cgi-sys/ \
            --with-chroot=/home/$user \
            --with-multiuser-cgi-dir=/var/www/cgi-bin \
            --with-httpd-user=www-data

i read and read again all cgiwrap.sourceforget.net'doc, search with many
keyword in google.. and after 12 days i'm in the same situation...

Re: [cgiwrap-users] problem with chroot.

[saturne <sa...@ka...>]

Message/home/user/etc -> /etc
/home/user/sbin -> /sbin
..............
and i have only hda1, not 2 partitions..


  ----- Original Message -----=20
  From: Neulinger, Nathan=20
  To: saturne ; cgi...@li...=20
  Sent: Monday, July 21, 2003 9:43 PM
  Subject: RE: [cgiwrap-users] problem with chroot.


  Does /home/... point to same data in chroot as outside of chroot?

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


    -----Original Message-----
    From: saturne [mailto:sa...@ka...]=20
    Sent: Monday, July 21, 2003 2:37 PM
    To: cgi...@li...
    Subject: Re: [cgiwrap-users] problem with chroot.


    for test, i cp -R all system, all librairies, mount root and MAKEDEV =
generic...  but it's the same thing.. it's very strange this problem. i =
want just an idea , about this problem, because i can't do anything =
without chroot.. I despair.

    thanks
      ----- Original Message -----=20
      From: Neulinger, Nathan=20
      To: saturne ; cgi...@li...=20
      Sent: Monday, July 21, 2003 9:20 PM
      Subject: RE: [cgiwrap-users] problem with chroot.


      There are several people on the list who will help with =
non-standard installations on a consulting basis. chroot is difficult to =
get right no matter what you're doing, most likely you haven't =
reproduced enough of the directory structure under the chroot to where =
things can still function properly.

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