cgi-bin problem

cgi-bin problem

Post by WLauma » Mon, 07 Jul 2003 01:40:58



Background:
1. Program works on real world paid hosting (linux server).
2. Program works on Windows home testing server.(Omnihttpd)

Just Installed Red Hat 8.0 .
Created cgi-bin for main site using..
ScriptAlias /cgi-bin/ "/path/to/my/site/"
and
Directory "/path/to/my/site/cgi-bin">
Allowoverride None
Options +Indexes
Order allow,deny
Allow from all
/Directory>
Program seems to work for the most part with a few exceptions.
Using the perl command "unlink" is not working,
and creating new files is not working.
Im thinking permissions but..
I'm running the program on the red hat box (as root) using the local
address(127.0.0.1).
Chmod 755.

Thanks for any advice
Wayne

 
 
 

cgi-bin problem

Post by David Efflan » Mon, 07 Jul 2003 07:57:23



> Background:
> 1. Program works on real world paid hosting (linux server).
> 2. Program works on Windows home testing server.(Omnihttpd)

> Just Installed Red Hat 8.0 .
> Created cgi-bin for main site using..
> ScriptAlias /cgi-bin/ "/path/to/my/site/"

Shouldn't that be:
ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin"

Quote:> and
> Directory "/path/to/my/site/cgi-bin">
> Allowoverride None
> Options +Indexes
> Order allow,deny
> Allow from all
> /Directory>
> Program seems to work for the most part with a few exceptions.
> Using the perl command "unlink" is not working,
> and creating new files is not working.
> Im thinking permissions but..

Yes it is permissions.  Unless you run CGI under suexec (as the webspace
owner), CGI is running as a common user that is not you and not in your
group.  So a directory would need something like 757 or 707 permission
(not healthy) and files would need 646 or 606 permission if they are not
owned by the user apache is running as.

Quote:> I'm running the program on the red hat box (as root) using the local
> address(127.0.0.1).
> Chmod 755.

Apache typically changes to a different user than root to handle requests,
once it binds to the ports it needs.  And it certainly is not going to be
able to tamper with dirs/files owned by root.

--
David Efflandt - All spam ignored  http://www.de-srv.com/
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

 
 
 

cgi-bin problem

Post by WLauma » Mon, 07 Jul 2003 10:21:32




> > Background:
> > 1. Program works on real world paid hosting (linux server).
> > 2. Program works on Windows home testing server.(Omnihttpd)

> > Just Installed Red Hat 8.0 .
> > Created cgi-bin for main site using..
> > ScriptAlias /cgi-bin/ "/path/to/my/site/"

> Shouldn't that be:
> ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin"

> > and
> > Directory "/path/to/my/site/cgi-bin">
> > Allowoverride None
> > Options +Indexes
> > Order allow,deny
> > Allow from all
> > /Directory>
> > Program seems to work for the most part with a few exceptions.
> > Using the perl command "unlink" is not working,
> > and creating new files is not working.
> > Im thinking permissions but..

> Yes it is permissions.  Unless you run CGI under suexec (as the webspace
> owner), CGI is running as a common user that is not you and not in your
> group.  So a directory would need something like 757 or 707 permission
> (not healthy) and files would need 646 or 606 permission if they are not
> owned by the user apache is running as.

> > I'm running the program on the red hat box (as root) using the local
> > address(127.0.0.1).
> > Chmod 755.

> Apache typically changes to a different user than root to handle requests,
> once it binds to the ports it needs.  And it certainly is not going to be
> able to tamper with dirs/files owned by root.

> --
> David Efflandt - All spam ignored  http://www.de-srv.com/
> http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
> http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

Thanks David for your time and insight.
 ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin" is the correct path...my
error in haste to post.

I still am lost however in how to correct this problem.
I have two IP addresses.
I have the server on one and my home computer on the other. I have tried
logging into server as root, connecting to the server through the lan and
connecting via the net. When connecting to the server i am unable to write
to a file or unlink or create a new file unless i set permissions to
777..(Very Bad) I have been using this perl script for years on both home
(windows)server and paid hosting using permissions 755. I thought that maybe
I have something incorrectly configured somewhere.
My root doc is not the default. All folders and files have had permissions
set to 755.

Thanks Again
Wayne

 
 
 

cgi-bin problem

Post by David Efflan » Mon, 07 Jul 2003 23:43:23






>> > Background:
>> > 1. Program works on real world paid hosting (linux server).
>> > 2. Program works on Windows home testing server.(Omnihttpd)

>> > Just Installed Red Hat 8.0 .
>> > Created cgi-bin for main site using..
>> > ScriptAlias /cgi-bin/ "/path/to/my/site/"

>> Shouldn't that be:
>> ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin"

>> > and
>> > Directory "/path/to/my/site/cgi-bin">
>> > Allowoverride None
>> > Options +Indexes
>> > Order allow,deny
>> > Allow from all
>> > /Directory>
>> > Program seems to work for the most part with a few exceptions.
>> > Using the perl command "unlink" is not working,
>> > and creating new files is not working.
>> > Im thinking permissions but..

>> Yes it is permissions.  Unless you run CGI under suexec (as the webspace
>> owner), CGI is running as a common user that is not you and not in your
>> group.  So a directory would need something like 757 or 707 permission
>> (not healthy) and files would need 646 or 606 permission if they are not
>> owned by the user apache is running as.

>> > I'm running the program on the red hat box (as root) using the local
>> > address(127.0.0.1).
>> > Chmod 755.

>> Apache typically changes to a different user than root to handle requests,
>> once it binds to the ports it needs.  And it certainly is not going to be
>> able to tamper with dirs/files owned by root.

>> --
>> David Efflandt - All spam ignored  http://www.de-srv.com/
>> http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
>> http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

> Thanks David for your time and insight.
>  ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin" is the correct path...my
> error in haste to post.

> I still am lost however in how to correct this problem.
> I have two IP addresses.
> I have the server on one and my home computer on the other. I have tried
> logging into server as root, connecting to the server through the lan and
> connecting via the net. When connecting to the server i am unable to write
> to a file or unlink or create a new file unless i set permissions to
> 777..(Very Bad) I have been using this perl script for years on both home
> (windows)server and paid hosting using permissions 755. I thought that maybe
> I have something incorrectly configured somewhere.
> My root doc is not the default. All folders and files have had permissions
> set to 755.

Even if SuExec is enabled, it only works in /~username/ URLs and virtual
hosts under the main DocumentRoot it was compiled for (assuming you follow
all the suexec rules).  For virtual hosts you would need to specify User
and Group and they would need to own any directories and files in that
virtual host with not more than 755 permission.  SuExec will not run
anything as root.

Without suexec, it is possible to run CGI as a specific user using suid
permissions, but that is usually ignored for scripts, and would require an
suid binary wrapper (small C program, etc.).

It is possible that those other servers were using apache suexec (or
separate cgiwrap).

--
David Efflandt - All spam ignored  http://www.de-srv.com/
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

 
 
 

cgi-bin problem

Post by WLauma » Tue, 08 Jul 2003 01:23:16







> >> > Background:
> >> > 1. Program works on real world paid hosting (linux server).
> >> > 2. Program works on Windows home testing server.(Omnihttpd)

> >> > Just Installed Red Hat 8.0 .
> >> > Created cgi-bin for main site using..
> >> > ScriptAlias /cgi-bin/ "/path/to/my/site/"

> >> Shouldn't that be:
> >> ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin"

> >> > and
> >> > Directory "/path/to/my/site/cgi-bin">
> >> > Allowoverride None
> >> > Options +Indexes
> >> > Order allow,deny
> >> > Allow from all
> >> > /Directory>
> >> > Program seems to work for the most part with a few exceptions.
> >> > Using the perl command "unlink" is not working,
> >> > and creating new files is not working.
> >> > Im thinking permissions but..

> >> Yes it is permissions.  Unless you run CGI under suexec (as the
webspace
> >> owner), CGI is running as a common user that is not you and not in your
> >> group.  So a directory would need something like 757 or 707 permission
> >> (not healthy) and files would need 646 or 606 permission if they are
not
> >> owned by the user apache is running as.

> >> > I'm running the program on the red hat box (as root) using the local
> >> > address(127.0.0.1).
> >> > Chmod 755.

> >> Apache typically changes to a different user than root to handle
requests,
> >> once it binds to the ports it needs.  And it certainly is not going to
be
> >> able to tamper with dirs/files owned by root.

> >> --
> >> David Efflandt - All spam ignored  http://www.de-srv.com/
> >> http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
> >> http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

> > Thanks David for your time and insight.
> >  ScriptAlias /cgi-bin/ "/path/to/my/site/cgi-bin" is the correct
path...my
> > error in haste to post.

> > I still am lost however in how to correct this problem.
> > I have two IP addresses.
> > I have the server on one and my home computer on the other. I have tried
> > logging into server as root, connecting to the server through the lan
and
> > connecting via the net. When connecting to the server i am unable to
write
> > to a file or unlink or create a new file unless i set permissions to
> > 777..(Very Bad) I have been using this perl script for years on both
home
> > (windows)server and paid hosting using permissions 755. I thought that
maybe
> > I have something incorrectly configured somewhere.
> > My root doc is not the default. All folders and files have had
permissions
> > set to 755.

> Even if SuExec is enabled, it only works in /~username/ URLs and virtual
> hosts under the main DocumentRoot it was compiled for (assuming you follow
> all the suexec rules).  For virtual hosts you would need to specify User
> and Group and they would need to own any directories and files in that
> virtual host with not more than 755 permission.  SuExec will not run
> anything as root.

> Without suexec, it is possible to run CGI as a specific user using suid
> permissions, but that is usually ignored for scripts, and would require an
> suid binary wrapper (small C program, etc.).

> It is possible that those other servers were using apache suexec (or
> separate cgiwrap).

> --
> David Efflandt - All spam ignored  http://www.de-srv.com/
> http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
> http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

Thanks David for you time.
I'm not the sharpest knife in the drawer.

The problem seems to be the Owner(user) of the file. If I  chown -R
apache.apache /path/to/my/cgi-bin
then the program works fine using chmod 755. The problem is then the owner
"admin" has no permissions via FTP.
Also would this problem also carry over to Virtual Hosts?

Just a thought...The httpd.conf has user/group left at default
apache/apache. If I change that to admin/admin then apache server would run
as admin, correct? But how would this effect Virtual Hosts?

Thanks Again,
Wayne

 
 
 

cgi-bin problem

Post by David Efflan » Wed, 09 Jul 2003 08:27:24




>> Even if SuExec is enabled, it only works in /~username/ URLs and virtual
>> hosts under the main DocumentRoot it was compiled for (assuming you follow
>> all the suexec rules).  For virtual hosts you would need to specify User
>> and Group and they would need to own any directories and files in that
>> virtual host with not more than 755 permission.  SuExec will not run
>> anything as root.

>> Without suexec, it is possible to run CGI as a specific user using suid
>> permissions, but that is usually ignored for scripts, and would require an
>> suid binary wrapper (small C program, etc.).

>> It is possible that those other servers were using apache suexec (or
>> separate cgiwrap).

>> --
>> David Efflandt - All spam ignored  http://www.de-srv.com/

> Thanks David for you time.
> I'm not the sharpest knife in the drawer.

> The problem seems to be the Owner(user) of the file. If I  chown -R
> apache.apache /path/to/my/cgi-bin
> then the program works fine using chmod 755. The problem is then the owner
> "admin" has no permissions via FTP.

Either way you would need to give write permission for 'others' for both
to be able to write or delete CGI data files, which would mean that most
anyone could modify them (via their own CGI if not from the shell).

Quote:> Also would this problem also carry over to Virtual Hosts?

It depends whether suexec is being used, the virtual hosts are below the
main DocumentRoot, and the 'User' and 'Group' that maintains the website
are specified in the VirtualHost (for apache 2.x see SuexecUserGroup).  I
do not think suexec can be used for the main server (just /~username/ URLs
and properly configured vhosts).

Without suexec, everything runs as the same user.

Quote:> Just a thought...The httpd.conf has user/group left at default
> apache/apache. If I change that to admin/admin then apache server would run
> as admin, correct? But how would this effect Virtual Hosts?

Probably NOT a good idea.  Default apache user should be a user that can
do the least amount of harm if a script can be exploited, or under suexec
as the particular user responsible, so you can tell who screwed up.

--
David Efflandt - All spam ignored  http://www.de-srv.com/

 
 
 

cgi-bin problem

Post by WLauma » Fri, 11 Jul 2003 01:20:20





> >> Even if SuExec is enabled, it only works in /~username/ URLs and
virtual
> >> hosts under the main DocumentRoot it was compiled for (assuming you
follow
> >> all the suexec rules).  For virtual hosts you would need to specify
User
> >> and Group and they would need to own any directories and files in that
> >> virtual host with not more than 755 permission.  SuExec will not run
> >> anything as root.

> >> Without suexec, it is possible to run CGI as a specific user using suid
> >> permissions, but that is usually ignored for scripts, and would require
an
> >> suid binary wrapper (small C program, etc.).

> >> It is possible that those other servers were using apache suexec (or
> >> separate cgiwrap).

> >> --
> >> David Efflandt - All spam ignored  http://www.de-srv.com/

> > Thanks David for you time.
> > I'm not the sharpest knife in the drawer.

> > The problem seems to be the Owner(user) of the file. If I  chown -R
> > apache.apache /path/to/my/cgi-bin
> > then the program works fine using chmod 755. The problem is then the
owner
> > "admin" has no permissions via FTP.

> Either way you would need to give write permission for 'others' for both
> to be able to write or delete CGI data files, which would mean that most
> anyone could modify them (via their own CGI if not from the shell).

> > Also would this problem also carry over to Virtual Hosts?

> It depends whether suexec is being used, the virtual hosts are below the
> main DocumentRoot, and the 'User' and 'Group' that maintains the website
> are specified in the VirtualHost (for apache 2.x see SuexecUserGroup).  I
> do not think suexec can be used for the main server (just /~username/ URLs
> and properly configured vhosts).

> Without suexec, everything runs as the same user.

> > Just a thought...The httpd.conf has user/group left at default
> > apache/apache. If I change that to admin/admin then apache server would
run
> > as admin, correct? But how would this effect Virtual Hosts?

> Probably NOT a good idea.  Default apache user should be a user that can
> do the least amount of harm if a script can be exploited, or under suexec
> as the particular user responsible, so you can tell who screwed up.

> --
> David Efflandt - All spam ignored  http://www.de-srv.com/

Thanks David...Truly appreciate your time!
 
 
 

1. cgi-bin problems

Hey guys,

I am having some problems... I am new to this whole apache server thing.

Anyways I am trying to set up cgi-bins for any user on my system.

When I use:

ScriptAlias /bin/ /home/<username>/public_html/bin/

(Form method is POST and Action is /bin/blank.cgi)

for a script it works fine.

However when I use:

ScriptAlias /~<username>/bin/ /home/<username>/public_html/bin/

or

ScriptAliasMatch ^/([^/]*)/bin/(.*) /home/$1/public_html/bin/$2

(Form method POST and Action is /~<username>/bin/blank.cgi)

and I get a server is misconfigured message (after restarting httpd). Of course <username> is
replaced by whatever users cgi-bin will be used.

I have tried stepping through this with no luck. Anybody out there who can point out what I need to
do.

Thanks,
Dustin

2. Problem with stalling during ftp transfers

3. cgi-bin problems.

4. Activating Interfaces

5. Cgi-bin problems!

6. Password management software?

7. Apache cgi-bin problems...

8. X11 with shared /usr for diskless WS

9. cgi-bin problem

10. Please help cgi-bin Problem

11. cgi-bin problems in apache

12. cgi-bin problems

13. Virtual hosting: cgi-bin problem