0

I would like to get some feedback on my setup of permissions and ownerships for the following directoriess:

  • /var/www/
  • /var/www/drupalsite.com

Right now I have the following for:

drwxr-x--- 11 root www-data 4096 2012-01-01 00:00 www
drwxr-x---  4 root www-data 4096 2012-01-01 00:00 drupalsite.com

I am a single user on this vps: developer1 in a group called : developers

  1. Is this secure and logical? A default ubuntu install starts with root as the owner and group with permissions of drwxr-xr-x but using those if I set these this /var/www/drupalsite.com becomes unavailable.
  2. What's the best to do if I want to be able to have write permission as developer1 to the files in /var/www/drupalsite.com?
  • Have you already stumbled upon this article: drupal.org/node/244924 ? I have also a linux setup but dedicated server, but i ended up studying this article over and over to try to understand the logic behind it, but it seems very athoritative article for the issue. I ended up customizing the script on the end of that article, which did permission setup on my Drupal installation. I am recommending it, as the permission problem dissapeared after i applied that script from ssh. You have to be cautios though, to apply that, i reccomend testing and sysadmin advice :) – NenadP Oct 1 '12 at 14:43
  • Yes I know that article :) But as I understand it's more for permissions on files and dirs inside the drupal root. – undersound Oct 1 '12 at 15:01
  • It also changes the ownership, you can customize the script. I was bold to apply it in my case, even in nearly-production phase ;) – NenadP Oct 1 '12 at 15:08
5

What I do is, on dev machines I make all of my Drupal files owned by my user account (e.g. developer1), and I make the group www-data. I use chmod g+w to give write access to the web server on the directories that need it (see article quoted above in question comments, http://drupal.org/node/244924).

On production and staging machines, I make all of my Drupal files owned by a special www-admin user, and give sudo access to www-admin to any user account (e.g. developer1) that might need it. I then can do, for example, sudo -u www-admin git pull if I want to operate on the Drupal files. (Aside: I usually store my git root at /var/www/drupalsite.com, and point the webserver document root at /var/www/drupalsite.com/htdocs. This puts the .git directory outside the web root, and also gives me another place to put file and directories that belong with the site, but should not be served by the webserver, e.g. D7 private folder.) If I am hosting on a small shared hosting site, I sometimes keep only the dev site under git revision control, and use drush rsync @dev @prod to push just the files over. By making the Drush site alias remote-user www-admin and setting the Drush rsync mode to 'rlptz' (e.g. $command_specific['rsync'] = array('mode' => 'rlptz');), then the filesystem modes will be copied over (so the folders that are g+w on dev will be g+w on prod), but all of the files will still be owned by www-admin on the target site.

I'm supposed to write some docs about this for Drush, but have not yet. :p See: http://drupal.org/node/1343892 and referenced issues.

Update: I'm in-progress on working on a Drush command to fix / set permissions. See http://drupal.org/node/990812. The default values used in that command give some hints on ways to set permissions, although different strategies are possible.

|improve this answer|||||
  • Thanks, this is helpful. To fully understand, on production + staging the /var/www/ folder (and all folders in there) will be developer1 u+rwx www-data g+r (with e.g. exception of files dir) – undersound Oct 1 '12 at 16:34
  • Yes, that is right, except that on production I do not make my files owned by developer1, but rather make some other user, to prevent accidental file overwrites. Editing files on production should be rare -- usually you will edit on dev or stage, test and then push -- so I find it's a good 'seatbelt' feature to require the sudo -u www-admin. I use www-admin instead of root so that I don't need to give root access to modify webserver files. – greg_1_anderson Oct 1 '12 at 16:56
  • This sounds good. One last thing, you write to prevent accidental file overwrites . Could you give an example scenario with what task that could happen? – undersound Oct 1 '12 at 17:22
  • Typically I am concerned about user error. This is rare, but annoying. If I have two open terminal windows open, one to my dev site and one to production, and if I want to modify a file on the dev machine, but I accidentally enter it in the production machine's terminal window instead, then I will get a permission denied error. Note that my prompt is different in both places, so I really have to be not paying attention to do something like this, but it is a good idea to set things up so that you never make errors instead of rarely make errors. – greg_1_anderson Oct 1 '12 at 17:54
  • That's a creative seatbelt feature for sure. Thanks for your time, helps a lot. – undersound Oct 1 '12 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.