Every time I install Apache to test a script, this question comes up for me. I don't do it very often, but I remember this being a pain point since about 2007.

A lot of tutorials/forums recommend using:

sudo chmod -R 777 /var/www/

But never mention that this is not for production or still recommend it even when the question specifies that the server will be public facing, but we don't want strangers able to write files to our server!

Another solution I found was to change the owner of the folder to your user, and then change the permissions:

sudo chgrp joe /var/www/html
sudo chmod 775 /var/www/html
sudo chown -R joe /var/www/html/*

But having ownership of publicly available and executing files strikes me as a bad practice, not to mention all files we might create in this directory will be owned by our user.

What are the implications of these and other bad practices? What are the correct ways to set up the users/permissions of a publicly facing web-server?

  • 1
    Part of it depends on what exactly your webserver is serving. Serving static pages, it probably doesn't matter, but a complex application has many more risks. – multithr3at3d May 17 at 20:04
up vote 5 down vote accepted

As you've noted chmod 777 is a particularly terrible idea. Owning the files yourself might not be as bad as you think; unless you horribly misconfigure Apache they'll still be executed by the Apache user (httpd, www-data, or something else, depends on distribution). There are several other ways to handle this as well.

Add users to the Apache group

Adding users to the group doesn't change the file permissions, but allows those users to modify the files as long as they use the default permissions of 775 for directories and executable files or 664 for non-executable files.

Give users permission with setfacl

Access Control Lists allow finer grained permissions, such as giving users access to specific directories. You can use setfacl as follows:

# -R for recursive
# -m for modify
# u:[user]:[perms] or g:[group]:[perms]
# Perm X instead of x means that execute permission will only be given if another
# user already has execute permission.
setfacl -R -m u:joe:rwX /var/www/html/joes-stuff

# -d modifies the default acl, so future files will have these permissions
setfacl -R -d -m u:joe:rwX /var/www/html/joes-stuff

# You can also do both at once
setfacl -R -m u:joe:rwX -m d:u:joe:rwX /var/www/html/joes-stuff

Restrict Apache permissions

It may be advantageous to remove Apache's write permission (at least to certain directories) so that a vulnerable script won't be able to write files. This is one of the benefits to having the files owned (or writable) by a user and group other than what Apache executes with.

  • 1
    Good answer but it's missing something so I'll add n answer to the original question: "What are the risks?" The risk is a fully compromised server. Apache is often used as an attack vector and for priv escalation. It's solid when configured correctly, but often anything web-facing is going to receive some attention from the wild web, so you want to make sure you keep it locked up TIGHT or you will be explaining to your CEO why your client's information is on pastebin. – SomeGuy May 17 at 21:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.