On Tue, Apr 10, 2007 at 07:15:56AM -0400, Davor Ocelic wrote:
> I'll do a quick test on permissions and let you know. If we set
> the log directory owned by www-data (or something which != user),
> I want to see if it will "cancel" the implicit permissions that user
> has by being the owner of the toplevel dir.
> 
> If yes, then we can just, as said, chown log directory to != user.
> If not, then yes, creating separate volumes will be the way to go.

Ok.

Situation seems good. Here's example:

$HOME/                               (chowned by $USER + 'all' fs perms)

        ./apache                           (either this and below is owned 
www-data)
        ./apache/log                       (or this and below)
        ./apache/log/deleuze
        ./apache/log/mire
        ./apache/log/mire/superdomain.com

The implicit 'i' permission that user gets on a directory when it is
chowned to him apparently does not propagate below the first level.

That said, implicit 'i' on $HOME does not allow user to create or remove files
within ./apache or ./apache/log, when one of those dirs is not owned
by him and he is not granted write permission.

He would only be able to remove the ./apache directory IF it was empty.
But if you create the initial structure (apache/log is enough, if 
we chown www-data ./apache directly), then he can't do that, and generally
can't mess with any files in there.

Users will be given read permission on apache (fs sa $USER apache read)
which will then propagate below when subdirs are created. So they will
be able to read but not mess up files.

That is simple solution.


Harder, better solution would be to create a volume. Good point about
a volume is that you can't overflow user's home quota by visiting 
their website with a script... Downside is, there will be less incentive
for people to do something about quota overruns if their home volume
is working normally.

Volumes would also be harder to set up, but since we don't need a new
user for them and since you have volume creation example already for
databases, maybe it would be a good idea to go with.

-doc

_______________________________________________
HCoop-SysAdmin mailing list
[email protected]
http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin

Reply via email to