httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Packwood <mal...@cray.com>
Subject Re: Unix permissions limitation
Date Mon, 22 Apr 2002 21:09:57 GMT
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
Mime
View raw message