Eric Toupin
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.
- You're working on a fairly standard Linux / Unix server (We'll say the Drupal install directory is at /public_html)
- Your client or third-party vendor has created a user for you (We'll call it supportperson)
- Your client or third-party vendor has either granted you root access or is willing to perform some operations for you as root
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 groupadd webadmin # As root, add each preexisting user, minus *apache* to your new group gpasswd -a adminperson webadmin gpasswd -a sysadmin webadmin # Don't forget to add yourself gpasswd -a supportperson webadmin # 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 chown -R apache sites/all/files/ # From the webroot, go down one folder then change the webroot directory's group cd .. chgrp -R webadmin public_html/ # Now add write and execute permissions for the webadmin group. You'll need this to go Drupaling chmod -R g+wx public_html/ # You're done here! Let's get out of root 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.