On Mon, Nov 06, 2006 at 11:42:25PM +0100, Francesco Poli wrote: > More in detail, web servers must obviously be able to read web content > (so that they can serve it); hence it seems that web content should at > least be readable by www-data *group*. Is that right? > Would it be wise if web content were owned by a regular user (say > user Ronny Regularuser, username 'ronny') who is the webmaster, and > by group 'www-data', and created with umask 0027? > Something like:
I don't think it would be wise, if the user 'ronny' was compromised the website would be defaced. root:www-data with mode 750 seems more plausible to me. > $ ls -altrF /var/www/test/ > total 16 > drwxr-xr-x 4 root root 4096 2005-11-01 18:47 ../ > drwxr-x--- 3 ronny www-data 4096 2006-09-09 07:55 old/ > drwxr-x--- 3 ronny www-data 4096 2006-10-08 10:23 cur/ > drwxr-x--- 4 ronny www-data 4096 2006-11-01 13:41 ./ > > What if more than one user needs to be able to create directories > inside /var/www/test/ ? It really depends on how you publish content to the site. Some people do it through some intermediate mechanism (such as CVS) some others do it directly to the site. The UNIX filesystems permissions allow just so much, if you have a complex setup you might need to go to extended ACLs. > Should webmaster(s) belong to group 'www-data'? Yes, webmasters should probably belong to www-data > Could a more detailed explanation of the recommended setup be included > in the section (or placed elsewhere and linked from this item)? Will try. > As far as the 'backup' user is concerned, assuming that I want > to perform both system and data backups, how can the 'backup' > user read all the files it needs to backup without having > superuser privileges? You can have a setuid-root local program that makes backups and can only be executed by the 'backup' user. > Could a more explicit description of the proposed setup be included > in the section (or put elsewhere and linked from here)? Will try, backups are complex things to do. It is typically best to have a cron job do the backup or have a backup client (which runs as root or runs setuid applications) that can be handled locally or remotely. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
