Take the 2-minute tour ×

I have a server that a few different coders will be using to work on various websites. Each coder will need to have access to each website.

There's two 'clean' methods I've come up with to do this but I'd rather avoid them...

  1. Each website is given it's own user/group to be owned by. The website would be stored in /home/username/www/ and I'll use Apache's suEXEC to switch between users/virtual hosts.

  2. I create one user/group on the system which each coder uses to login as. Websites can then be stored in /var/www/website.com/ and Apache will run as that user to have read/write access to the files

The obvious security benefits to point 1 is that each website is sandboxes. If one site is compromised, the other sites should be safe. The downside to this method is having multiple usernames/passwords for each coder to remember.

Point 2 means each coder has one login (the same login...) and there's less clutter (50 websites on the host means 50 new users/groups)

My ideal setup was to give each coder their own user/group. This would give them their own ~ folder for storing their stuff and, if I need to revoke a coder's access, I'd simply disable their login. This beats having to change the password for each website/coder's account.

The reason I can't rely on a version control system is that it'll rarely be used. A lot of the sites on this host will be using Joomla/Wordpress/etc.

So I'm basically looking for a clean and secure way for multiple coders to work on multiple, shared websites on the one host. What do you suggest?

share|improve this question

2 Answers 2

Allowing multiple people to edit production code is asking for a world of hurt. Use version control and deploy only tagged builds.

How you deploy build is not nearly as important as tracking the changes and being able to back out.

share|improve this answer
For sites we could ourselves we will certainly be using version control. However, a lot of the sites will be simply using Joomla. Once that's installed and had a few customizations here and there, it won't be touched again. For that, version control seems overboard. –  ben Jan 28 '11 at 4:00
Yes. It seems overboard until the site suddenly breaks and you don't know why. –  Chris Nava Jan 28 '11 at 4:38
When I say "won't be touched again", I mean that literally. We have website sitting on a server that were coded months ago. No changes made so far and no changed planned. There small sites for people that want specific things. So, for those sites, I can honestly say I'm not concerned about changes being made to the point where I want to track them. –  ben Jan 28 '11 at 5:05
In that case, why do the coders need access at all? –  mattdm Jan 28 '11 at 5:46
Websites will be regularly added. Each coder needs the ability to upload the website (Joomla CMS, mainly) to the server. –  ben Jan 28 '11 at 6:10

While I agree that version control is a fantastic option, you can pull off what your asking for by doing the following (again, pay special attention to the concerns listed about version control).

So here's an answer to your Question:

Create two users and give them the same group id

 #groupadd -g 5000 programmers
 #useradd ren
 #useradd stimpy

Edit your /etc/passwd file and change your guid for your two users:


Next, change the umask for these users so that they create all their file with rw for the group programmers

 #vi /home/ren/.bash_profile
 umask 002

Now, su to each user to see that they can both edit the same files going forward:

 #su - ren
 #vi /path/to/file.txt
 here's some content in the file


 #su - stimpy
 #vi /path/to/file.txt
 append some more content

You'll find that when ren created the file, the ownership was ren:programmers with rw-rw-r. This will allow stimpy to also edit the file. You'll also be able to keep track of how originally create the file (but not who edited it).

share|improve this answer
Something similar can be accomplished using the group sticky bit (chgrp programmers wwwroot; chmod 2775 wwwroot) without having to have both users with the same primary group. Instead you can just add them to the programmers group as you normally would. –  Chris Nava Jan 28 '11 at 15:17
+1 @Chris - I've never tried it that way. I'll test it out, thanks. –  Patrick R Jan 28 '11 at 15:21
I think the umask should be 002 in order to allow group write in either case. –  Chris Nava Jan 28 '11 at 15:40
Thanks Chris, that was a typo. the 022 is the default. update made above. –  Patrick R Jan 28 '11 at 17:24
@ Chris - I tried your method with chgrp and chmod g+s and really liked it. glad you pointed that out. –  Patrick R Feb 8 '11 at 20:36

Your Answer


