[cobalt-users] (no subject)

[PCAP/Las Vegas Leisure Guide <pcap@xxxxxxxx>]

>In the response to Knowledge Base Question 696 regarding CGI Wrap, Cobalt
>support states that httpd should be a member of every virtual site group:
>-------------------------------------------
>QuestionNum: 696
>      Product: RaQ2
>      Category Intranet
>      Creation Date: Sat Jan 08 17:14:16 2000 PST 
>
>      Question
>      How do I disable CGI wrap on a RaQ2?
>
>      Response
>      ** NOTE ** Disabling CGIWrap will void your warrenty. 
>
>      cgi-wrapper sets script permissions to those of the user who owns the 
>      script. Without cgi-wrapper (or Apache's SUEXEC, or a handful of other 
>      similar programs) cgi scripts will be run with the permissions of the 
>      web server. If you look at the contents of /etc/group, you'll see that 
>      httpd is a member of all virtual site-associated groups. So if you run 
>      scripts without cgi-wrapper, the script will be able to write to files 
>      that are group writable, like almost every file in /home/sites.
>---------------------------------------------------------------------------
-----
>If this were indeed true it would be fabulous for us as then we would not
have to make every file which is to be written by the cgi a chmod 666. we
could make it 664 and the user world would not have access to everything.
However, on our RaQ2 the group file looks like the below. As far as I  can
see unfortunately httpd is NOT a member of every virt site group, ADMIN is,
Thus .cgis executed with cgi-script rather than cgi-wrapper still CAN NOT
write files unless they are 666. Incidently we would use cgi-wrapper, but
it doesn't seem to allow file writing even if the file is owned by the same
owner as the .cgi. Isn't it supposed to do this?

> Is this a bug for which there is a patch? Can we add to the group file
without voiding the waranty? Will the group file be changed back every time
we make a virtual host change from the browser screen? Or am i I missing
something?
>
>BTW, we had originally modified the srm.conf and httpd.conf as suggested,
but changed them both back to the original since 1. The Execute CGI flags
got set to empty on the browser screen interface when we pulled the host
screen up again and 2. The httpd.conf file gets overwritten every time the
hosts are updated anyway.
> Instead we inserted a 644 protected .htaccess file in the web directory
where the .cgi is containing The AddHandler cgi-script .cgi and Options
Includes ExecCGI . Then we simply chown'd the .cgi to httpd. Crude but
effective for a trusted multi-user machine.
>
>----------------------------------- etc/group -----------------
>root:x:0:root
>bin:x:1:root,bin,daemon
>daemon:x:2:root,bin,daemon
>sys:x:3:root,bin,adm
>adm:x:4:root,adm,daemon
>tty:x:5:
>disk:x:6:root
>lp:x:7:daemon,lp
>mem:x:8:
>kmem:x:9:
>wheel:x:10:root,admin
>httpd:x:11:httpd,daemon
>mail:x:12:mail
>news:x:13:news
>uucp:x:14:uucp
>man:x:15:
>squid:x:16:squid
>games:x:20:
>gopher:x:30:
>dip:x:40:
>ftp:x:50:
>nobody:x:99:
>users:x:100:httpd
>home:x:110:admin
>site-adm:x:111:admin,abc,def,fgh, ghi, hij,uvw,wxy,xyz
>admin:x:27:admin
>site1:x:112:admin,uvw
>site2:x:113:admin,wxy
>site3:x:114:admin,xyz
>site4:x:115:admin,abc
>site5:x:116:admin,def
>site6:x:117:admin
>site7:x:118:admin
>site8:x:119:admin,fgh
>site9:x:120:admin,ghi
>site10:x:121:admin,hij
>