Hi all,

How do i allow multiple users to make changes to a website consisting of some static html pages on Apache, with the document root as /var/www

I would like to avoid having users su to root and then make these changes, I have tried creating individual users for this purpose and adding them to the group --> www-data. This doesn't allow me to scp/sftp files to /var/www when logged in to those User IDs.

While I am running Apache on Debian, the users who will be modifying the website will probably be accessing it via Windows.

Thanks in advance,
Sabu

Please, remove the users from www-data. They don't need to be there. The group www-data exists only to provide an uprivileged user for the web server daemon, as such it should generally not be give write access. Sometimes an edge case pops up for a specific directory, but this is not one of them.

About actually sharing the directories among several users, consider the following blog entry: Sharing Write Access to a Web Directory for Multiple Users

2 members found this post helpful.

Apache should not be able to write to files it can then read/execute, this is more so true if you are using DSO/mod_php. Tho I always advise against mod_php personally, while PHP-FPM takes more configuration it is, when set-up correctly, vastly better in almost every way.

Turbocapitalist's guide is definitely a good base to start with, you'd be surprised how many guides actually give really bad info or the forum posts that say to 777 everything (which is exceptionally bad). Just to state why Turbo's guide is good, if your apache daemon got hijacked, compromised or just tricked then it could be made into editing or creating various different files such as javascript, css or php files. Also if you have overrides enabled(not recommended), .htaccess files could be modified/created too.

Group permissions that apache has no access too are the way forward, Also ensure that apache is not the owner of any files it serves. 664 doesn't protect you if apache is the owner.

Also, I suggest that you should use version control ("git") to manage the web site's content.

To update the site, users "pull" from the git repository, make changes, "commit" those changes, and "push." Then, to actually update the website's content, someone logs-on as a particular user and does a "checkout" and "pull."

Thus, if someone hoses-up the site, it's actually no problem: you can quickly and reliably restore the site's content to any previous state.

4 members found this post helpful.

Hi,,

You can do thing by using access control list,,

1. add the user
2. Give access control list to the users like "setfacl -Rm u:"username":rw -d /var/www/*
3. Then user may have access to access the /var/www/* without interruption

regards
Yadheesh Jey

This....+1.

Git or some other content management system will make your life MUCH easier. Using access control/setfacl/permissions is not a good way to go for what you're trying to accomplish. Aside from being able to roll back a change (as sundialsvcs noted), think about adding more users in the future. Do you really want to add yet MORE complexity to user management, for no good reason? Adding them to the project repository is all you need...can even give some users read-only, so they can check thing out (proofreading/etc.), while letting others update the site.

1 members found this post helpful.

Also: if multiple users can directly read/write the directory, any of them can ...

... and eventually will ...

... ... "oopsie!™" ...

With the scenario that I describe, each user is working on their own [private] copy of the version-control repository on their own machine. (Perhaps they are also testing the web site on their own machine.) They might be working on one "branch" while someone else is doing completely-unrelated changes at the same time on another "branch." Meanwhile, the main web-site remains both stable and accountable.

No one has read/write access to the actual web-site directory except the user which is responsible for maintaining it ... that is to say, the user who every now and then logs on and does a git pull and then a git checkout of the appropriate production-branch (at the agreed-upon "tag" point in that branch).

(The web-server runs under a userid which does not have read/write access to the files that comprise the web-site that it is serving!)

"Oopsie!" Awright, first we checkout at the previous tag – thereby accurately restoring the site to its last approved-good state – then we use commands like git blame to determine precisely who made the erroneous change, when and why. (However, we're able to do all of this in our pre-launch test environment, so that live-site users never see our "oopsie" at all.)

git - don't leave home without it!

1 members found this post helpful.

@sundialsvcs - thanks GIT seems to be the way to go. Just one more query on this, pardon me if it seems too basic, what would be better? setting up GIT on a separate machine or having it on the same computer?

@Turbocapitalist - i presently have all files in /var/www user:group as www-data:www-data. From what you've said, i need to change it another non-root user perhaps?

Any user will do as owner, even root, as long as it is not the same user as what the web server is using. It looks like in your case www-data is probably what the web server is using, so it should be avoided. The group should also be anything except www-data, but with the additional constraint that its members be those who should be allowed to write.

But that said, you have another +1 vote here from me for git or even svn.

PS. I'd worry about the problem that your people are connecting from Windows and would recommend finding a way to locking down the connection to the server from such machines. If you are using SFTP to transfer files, that can be made to use a chroot and locked into SFTP only, preventing shell access. That limits the damage they will be able to do to the server when the machines are compromised later. Eventually those machines should be put in the queue for upgrading to Linux Mint or TrueOS or something a little more sound yet more flexible.

hi all, thank you everyone for replying.

while I setup GIT, heres what i have done so that we can continue to work on the website (hope to hear from you all on this)
1. Created a group - webs (#groupadd webs)
2. Created two users - one, two (#adduser one, #adduser two)
3. Added one & two to Group webs (#usermod -aG webs one, #usermod -aG webs two)
4. Then changes ownership of /var/www recursively to one:webs (#chown -R one:webs /var/www)
5. Then changed the permissions on /var/www to 775 (#chmod -R 775 /var/www)

This seems have gotten the job done pending GIT.

Hope this isn't making the server insecure! Please let me know if i am missing something...

It won't be insecure if you have only static XHTML and other static files under /var/www/ However, if you have scripts, you may want to narrow the group changes to just the DocumentRoot. Often that is /var/www/html/

One thing missing is that you'll also need to set the SetGID bit for the web server's DocumentRoot directory so that the right group permissions get applied to newly created files. Otherwise, your staff will squabble over who owns what. See the blog post linked to earlier for that, but look around on the net for info about SetGID if needed.

They will be "squabbling" soon enough – just as soon as two of them try to edit the same file at the same time and one's changes overwrites the other's.

With version control, two people can edit the same file at the same time, as long as their changes do not conflict with one another. (And if they do, you can "resolve" it.)

Except when you get into permission issues because one user has no ability to pull a new git clone. The fact it is using git is in my opinion MORE reason to use SGID, not less. Unless of course you wanna sudo it instead.