cgi-bin problem

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

On Sat, 5 Jul 2003 09:40:58 -0700, WLauman <wlauman@email.com> wrote:
> 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/

"David Efflandt" <efflandt@xnet.com> wrote in message
news:slrnbgeluj.t3h.efflandt@typhoon.xnet.com...
> On Sat, 5 Jul 2003 09:40:58 -0700, WLauman <wlauman@email.com> wrote:
> > 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

On Sat, 5 Jul 2003 18:21:32 -0700, WLauman <wlauman@email.com> wrote:
>
> "David Efflandt" <efflandt@xnet.com> wrote in message
> news:slrnbgeluj.t3h.efflandt@typhoon.xnet.com...
>> On Sat, 5 Jul 2003 09:40:58 -0700, WLauman <wlauman@email.com> wrote:
>> > 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/

On Sun, 6 Jul 2003 09:23:16 -0700, WLauman <wlauman@email.com> wrote:
>
> "David Efflandt" <efflandt@xnet.com> wrote in message
>> 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/