Server Permissions

Permissions on webservers are a hassle if not setup correctly. It’s one thing to setup everyone with their own group if they aren’t going to be editing each others files but in an environment with multiple editors it’s not a good idea, IMO.

The best way I’ve found so far to clean up my permissions, with the help of Qunu.com, was the find command.

# find /path/to/dir -user [username] -group [groupname] -exec chown newown.newgroup {} \;

and then I need to make sure the files are group writable

# chmod g+w /path/to/dir

If you want to do Recursive changes put the -R option after the command of ‘find’ or ‘chmod’.

Since I already cd into the directory and I only need to edit the groups I used these:
# find . -group [group] -exec chown :[newgroup] {} \;

# chmod g+w *

I’m still hesitant with this solution, probably because this is the only option I know right now.

More importantly, what’s the best practice for webservers with multiple editors and developers? Dav and Samba? I wonder how Subversion handles permissions since that’s what we are going to deploy in our next system.

About the Author, Dan Cameron:

I'm the owner and solution engineer at Sprout Venture, a web solutions company that specializes in web development including WordPress.

I started my first blog in 2003 and transitioned to WordPress in 2004. Since moving to WordPress I've written a few plugins and themes for public consumption. Lately I'm busy engineering/building/coding and have only been able to share a few code snippets.

If you're in need of some web development, web design or custom WordPress plugins and/or themes contact me, I'll be happy to discuss it with you.

Read More »

  • Dan
    I like Nate's plan for now and Jared's stuff is pretty much "standard" and that's how we are planning our future setup with subversion.

    I only through Samba and WebDAV out there without thinking about it.
  • Add the necessary users to a common group and set the group sticky bit of the top most directory. Then any files created under that directory will automatically be owned by the common group. All files should be kept group writeable. If anyone deviates from that rule they get fifty lashes with one of the extra power cords.
  • Best practices in this regard are probably widely debated, but I think one thing that most people can agree upon is that a "production" web server (meaning something that you depend on to run your business) should be locked down as tightly as possible.

    For me, this means a few things as it relates to this particular discussion:

    1. Never run any services on your server that are not essential to the production purpose of that server. This would include things like Samba, in all instances I can think of.

    2. Closely related to the previous point is that in a corporate environment, your internal people should be firewalled off from accessing your web server just as external people are. The common term for this is a DMZ. A basic summary of this (for those who don't know) is that your server should be on a network that is protected both from internal and external access. There should be a firewall on the public facing side that blocks all traffic except that which is desired from the public internet, and there should also a firewall on the internal side that is as tightly controlled as possible, only allowing people who really need to admin the box to have access (via SSH is probably the only port that you should need open from the internal side).

    3. All changes not made by you (the administrator of the server) should be made on a development server that is a separate machine, set up to mirror the configuration of your production server. Then you can open up permissions on that server a little looser and allow whoever needs to edit files to do so, and then have the person or people responsible for the production server migrate those changes onto it. Ideally, you'd actually have an intermediate server in the mix as well, where the changes are made on the dev server, packaged up, and deployed to a test server (which is an exact duplicate of the production system). Then you can use that test server to validate that the package you just added is good, and only then do you add that "known good" change/package to the production server.

    That may be more detail than you were looking for, but oh well. Subversion is a good approach as well, since that would allow you to better manage how the files are changed, since they can be checked out/in from local workstations as well as the development server, etc. so you wouldn't have to worry about configuring special access there. You could even just give them a script that they can run on the dev server to sync it up with the subversion repository, and just have them make all their changes through subversion (checked out and in from their workstations), so everyone would only need access on the dev box to run that one script.
blog comments powered by Disqus