Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Sender: malice@cray.com
Message-ID: <3CC47C25.9F3E3@cray.com>
Date: Mon, 22 Apr 2002 16:09:57 -0500
From: Ted Packwood <malice@cray.com>
Organization: Cray Inc.
MIME-Version: 1.0
To: users@httpd.apache.org
Subject: Re: Unix permissions limitation
References: <3CC44AB4.A2D3D6EA@cray.com>
 <20020422110852.3093acd6.ahawkes@unicon.net> <3CC47438.CB460932@cray.com>
 <3CC47771.1060509@slive.ca>
Content-Type: multipart/mixed;
 boundary="------------0DC5ABFAA443F5CB7A8B6E22"

--------------0DC5ABFAA443F5CB7A8B6E22
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joshua Slive wrote:
> 
> > Andrew Hawkes wrote:
> >
> >>Why do they need to belong to the group to edit files? What about
> >>
> >>-rw-r-----  webuser1  nobody  blah.html
> >>-rw-r-----  webuser2  nobody  foo.html
> 
> I think you are wrong Ted.  Andrew's suggestion was that *neither* user
> actually belong to the "nobody" group.  Only apache runs under this
> group.  Then webuser1 would not be able to read foo.html.  The problem

Ah, I can see I really haven't made myself clear.  Here is a 
generic breakdown of the situation

webgroupA  has members webuserA1 webuserA2 webuserA3 etc
webgroupB  has members webuserB1 webuserB2 webuserB3 etc

Everyone in webgroupA needs to be able to edit and read each
other's files, but should not have access to webgroupB's files.
webgroupB needs to be able to edit and read each other's files
but should not have access to webgroupA's files.  

So
-rw-rw----  webuserA1  webgroupA  blah1.html
-rw-rw----  webuserA2  webgroupA  blah2.html

-rw-rw----  webuserB1  webgroupB  foo1.html
-rw-rw----  webuserB2  webgroupB  foo2.html

is minimally required.  However, the httpd daemon needs to be
able to read both webgroupA files and webgroupB files.  

> Another "solution" I've seen to this problem is to have each users files
> in a subdirectory of a directory that has permissions
> --x--x--x-
> Then the subdirectory name intself is kept secret and acts as sort of a
> password to view the files, which are themselves all world readable.
> (Obviously, you need to use hard to guess names.)  This is basically a
> "security through obscurity" approach, but could be made to work as long
> as the stuff you are protecting isn't *too* sensitive.

That's an interesting idea, but I know it won't fly with
the security team.  =)  Thanks though.

Ted
--------------0DC5ABFAA443F5CB7A8B6E22
Content-Type: text/x-vcard; charset=us-ascii;
 name="malice.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ted Packwood
Content-Disposition: attachment;
 filename="malice.vcf"

begin:vcard 
n:Packwood;Ted
x-mozilla-html:FALSE
url:http://www.cray.com
org:Cray Inc.;Information Services
adr:;;1340 Mendota Heights Road.;Mendota Heights;MN;55122;USA
version:2.1
email;internet:malice@cray.com
title:Unix System Administrator
note;quoted-printable:Webserver Administration=0D=0AMajordomo Administration
x-mozilla-cpt:;5040
fn:Ted Packwood
end:vcard


--------------0DC5ABFAA443F5CB7A8B6E22
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
--------------0DC5ABFAA443F5CB7A8B6E22--