Web Designer Permissions on a Production Web Server [closed]

Just started working with a small group of front-end web developers who all login to the dedicated WHM/Apache production server with root to modify client web sites. They claim they do not want to have to log into each of the individual site accounts because there are so many.

I'm not an experienced sysadmin but I know this is wrong.

What is the best way to create logins for these developers and assign permissions to have full rwx privileges to all client assets in the /home/ directories?

Additional Information: * When I say developers I mean CSS/HTML front-end designers. Our developers use git as a CVS and do not work on the server until we push new versions of the CMS.

Solution 1:

I'm not an experienced sysadmin but I know this is wrong.

Actually, what's really wrong is that there are developers on your production machines. :-/ (Your life will be better when you have another machine for them to test their changes on and a scripted way to get those changes to the production setup. Your life will really get better when they're checking their code into a central source code repository (svn or the like) and deploying it to a staging environment for testing, and only then to to production.)

Unfortunately, I'm not sure I can provide much constructive advice without knowing more details about your situation, but here are a few things that may help:

• Set up sudo to allow your developers to do things as the individual clients
• Use group-writable modes on the directories in question

Solution 2:

Create a developer group, and chown all the files as that group. Then give g=rwx to all the files.

Also, having developers edit the sites I would think is a sign of bad work flow. My recommendation of a simple release management would be:

Have the websites checked into a code repository using something like subversion. Then have them create tags with deployment instructions. Then the admin can deploy using those tags and deploy instructions and ideally automate that process. Also, the admin can make sure there is a strategy to revert back.

Solution 3:

From a security standpoint, I would recommend putting the individual sites in a different directory structure entirely, and linking to them via vhosts. I.e. /var/www/client1, /var/www/client2. From there create a new group called webdev (or whatever), and give that group write permissions to the /var/www/client* trees.

That being said, I would also recommend putting up a test and/or Q/A environment to make the changes, then once verified have them rolled out to the production server. Ideally, the webdevs would not have access to the production system, and a separate web admin, or webmaster would be the one to roll out the new pages. Whether your culture could support that kind of separation of duties is another matter entirely.

Solution 4:

Personally I believe a developer shouldn't have any rights on production box but that's because I came from a very rigid background where we used Rational Unified Process as law. Dev was theirs to do what they wanted with, Acceptance they had limited rights but changes went through me (sysadmin) and Production they had no rights to and any/all changes went through me on a scheduled day unless the change was emergency. What it really comes down to is what your management policy is on the issue. If its only a small shop then obviously what I just outlined is massive overkill but still good practice to think about. Best thing is to go with least privilege mindset and only give them what they need. All else fails just make sure you're getting good backups to rollback whatever changes may screw things up (fyi snapshots with VM's are a godsend for these sorts of changes just don't let the snapshots live more than 48 hours or they bloat).