0

This question has been asked time and time again but none of the answers seem to answer my specific question - either that or I'm not getting it.

Anyway, as per the title, I'm trying to limit our web developers to a particular folder eg: /var/www/site1.com and ensure they are able to edit files that end up belonging to www-data.

So far I have managed to do so by appending a match rule to sshd_config for users in group sftp and chrooting the user dev to their home directory where I mount --bind /var/www/site1.com/ /home/dev/site1.com and chown -R dev:www-data /var/www/site1.com/.
I then chmoded all files to 644 and dir's that need to be written to, to 775.

This has been working perfectly so far except for files that are uploaded through the site itself to /var/www/site1.com/public_html/uploads/ which are not editable by user dev because once uploaded by the site's visitors end up belonging to user www-data.

I suppose I can add a cron to change permissions on a regular basis but surely there is a better to do what I'm trying to accomplish?

Webserver is Nginx with php5-fpm on Ubuntu 14.04.

Thanks!

Touff
  • 183
  • 1
  • 3
  • 14

1 Answers1

0

Problem

To me, there is no simple solution to your problem: even if you postpone the ownership change, you will need to swap it twice again the next time you want to edit/maintain a file.

That results in a two-headed environment: sometimes developers are allowed to edit stuff, sometimes they are not... Why is that so? If it is a production server, they should not use it as a playground, if it is a development server, they should never be restricted editing content!

Proposed solution

I would suggest you need to rethink how your setup is built:

  • Use a production environment where only automated publishing tools (Git? rsync?) have the means and access rights to change (publish) content
  • Use (a) development environment(s) where developers are happy to mess things up
  • Additionally, one usually use a 'staging' environment where test content is used in a setup imitating production, just to be sure everything works well and where to run test simulating the real-world

To solve the problem of multi-access to files, I would recommend using the access control mechanisms built in the Linux filesystem mangement, with the default rights:

  1. user (owner) has rw rights --> Use it for content modifier(s), ie developers in development environment, publishing tool in staging/production
  2. group has r rights --> Use it for content accesser(s) (ie Web server, backend applications, etc...), making sure all those belong to group

Special cases such as directories where Web server/applications need write access, such as an upload directory, make an exception by adding the w for group permission to this directory (or make this specific directory locked to anyone else by making it owned by group)

Now, to automatically make new files being readable by the Web server/applications, you can use the setgid flag from the filesystem permissions. This will automatically change the group of any added file to group.

Sum up

Here is a quick example so sum up everything:

Your web server and any backend application belong to the www-data group.

You have a /srv/www/ Web root on 2 environments:

  1. Development, with owners dev:www-data and rights 4755 rwxr-sr-x
  2. Production, with owners git:www-data and rights 4755 rwxr-sr-w

To update content in Development, use the dev account or any tool using that user.

To update content in Production, use the git tool rightly configured to push data at the corretc location, using the git user.

Bernard Rosset
  • 1,373
  • 12
  • 25