Authors
Eric Toupin
Director of Growth Strategy
Our support and maintenance customers aren't always previously existing clients of ours. In some cases, we're brought onboard to extend, modify or maintain existing Drupal websites that were created and configured by a different vendor. We absolutely take pride in being a go-to resource in terms of Drupal maintenance and support, but jumping into a project mid-life can present a variety of, well, crises. One of those is file permissions.
Permissions getting you down
Every systems administrator has their own custom tailored approach when it comes to file permissions. In some cases this approach is fairly straightforward; in some cases it's not. And then there are servers that have gone through a variety of administrators, each leaving their respective evidences in the form of users, user groups, filesystem owners and the like. When it comes to support and maintenance, my primary goal isn't to call server administration shots. My first order of business is simply to gain the access I need to begin module upgrades, front end adjustments and custom development without stepping on anyone's toes or blowing a server's security wide open.
There are probably a few approaches to ironing out file permissions before digging into to the real fun Drupal development stuff. Here's the one I took:
When it's a group thing, nobody gets left out
The basic idea is to create a new user group, add all current filesystem owners to that group, grant the group appropriate access, then change the Drupal base directory's group to your new group. This will provide the access necessary for you to get on with your Drupal administration without cutting in on any users' pre-existing permissions or file ownership.
In order to proceed with the approach I'll be outlining, I'll be making three assumptions. If these don't sound like your situation, you may want to check out a different solution.
Let's say that file ownership of your base Drupal directory is distributed between several users: root, apache, adminperson and sysadmin. Your user, supportperson, doesn't own a thing. Time to make this a group affair:
# As root, create a new group<br /> groupadd webadmin</p> <p># As root, add each preexisting user, minus <em>apache</em> to your new group<br /> gpasswd -a adminperson webadmin<br /> gpasswd -a sysadmin webadmin</p> <p># Don't forget to add yourself<br /> gpasswd -a supportperson webadmin</p> <p># Adding apache to your new group may introduce some security concerns, but you still need to ensure apache can read and write from the files directory. We can just change the files directory owner to apache<br /> chown -R apache sites/all/files/</p> <p># From the webroot, go down one folder then change the webroot directory's group<br /> cd ..<br /> chgrp -R webadmin public_html/</p> <p># Now add write and execute permissions for the webadmin group. You'll need this to go Drupaling<br /> chmod -R g+wx public_html/</p> <p># You're done here! Let's get out of root<br /> exit
That's it! At this point your user, supportperson, should have everything it needs to manage your Drupal website. You're also done with root access, so you won't need to play Russian Roulette every time you want to poke around on the server.