66

I'm trying to not give 777 permission in my /var/www/html folder, but I want to edit my files without sudo. So I thought to create a symlink of a folder in my home directory within /var/www/html. I created it using:

sudo ln -sT /home/andre/www/moodle/ moodle

and the ls -la output is this:

andre@andre-270E5G:/var/www/html$ ls -la
total 8
drwxr-xr-x 2 root root 4096 Mai  4 10:20 .
drwxr-xr-x 4 root root 4096 Abr 29 14:29 ..
lrwxrwxrwx 1 root root   23 Mai  4 10:20 moodle -> /home/andre/www/moodle/

So, my moodle folder has read, write, and execute permissions for everyone, and that's not what I want. I used the command:

sudo chmod -R 775 moodle/

trying to change it, but it stayed with read, write, and execute permissions to all. I tried the same with the moodle folder in /home/andre/www/moodle, but it stayed the same. The output of ls -la in /home/andre/www/ is:

andre@andre-270E5G:~/www$ ls -la
total 28
drwxrwxr-x  3 andre andre  4096 Mai  4 10:02 .
drwx------ 49 andre andre 20480 Mai  4 10:01 ..
drwxrwxr-x 41 andre andre  4096 Mai  4 10:02 moodle

So the folder moodle in /home/andre/www/ has the permissions I want.

As an additional problem, when I access localhost/moodle I get 403 Forbidden error.

What am I doing wrong here?

3 Answers 3

113

You should never have to run a website from within your home directory. EVER. You would otherwise have to give the web server the ability to traverse through /home/ to see the directory structure, but also into /home/$USER/ (your user's home directory, where we can try and see what else exists in your user directory), as well as any other subfolders in there. A poorly-configured or misconfigured or unpatched web server can cause massive data leakage this way, or loss of credentials and such which would put your personal data and logins on different things at risk. The symlink approach you are using doesn't help either for the same reason as trying to give Apache permissions to read /home/andre/www/moodle - the web server has to be able to traverse your home directory to get to the location that the symlink in /var/www/html points to, which still poses that security risk.

Firstly, use sudo cp -r /home/andre/www/moodle/ /var/www/html/. This will copy your files to /var/www/html, and keep it away from your own home directory. We'll then redo the permissions so you and the web server can access everything in that directory, and give your user full read/write to all the files and directories. Then, you will only ever have to work out of /var/www/html for your site.

This is in effect, four steps, after you copy your data back to /var/www/html:

  1. Give Apache access to the folders and files, so it can serve the site without 403 errors.
  2. Give your user 'owner' over the files and folders, and give yourself read/write on all of the files and folders, as well as the ability to traverse the directories.
  3. (Optional but recommended) Set it up such that any files or folders created from hereon in the entirety of the directory structure has the group set to be www-data.
  4. (Optional) Final security cleanup, where we set up permissions so you and the web server can see the site data, but other users cannot access files or the directory structure for the site.

(1) Allow Apache access to the folders and the files.

sudo chgrp -R www-data /var/www/html
sudo find /var/www/html -type d -exec chmod g+rx {} +
sudo find /var/www/html -type f -exec chmod g+r {} +

This recursively sets the 'group' to be www-data for the folders and files. This then gives the web server permission to recurse and get access to the site document root directories structure (+x for directories only). It then also ensures the web server has read permissions for all files, so site data can be received.

There may be some cases where you have to give the web server write permission to a file, or to a directory - this can be achieved by doing sudo chmod g+w /var/www/html/PATH (where PATH is the path to the file or folder in the directory structure where you need to apply the write permissions for the web server).

NOTICE: There are a lot of cases where this may expose 'secure' information about a site configuration (such as database access credentials, etc.), and you should remove 'other' access permissions to that data on those individual files or directories with the following: sudo chmod o-rwx /var/www/html/FILEPATH (replacing FILEPATH with the path relative to the /var/www/html folder for the file).

Note also that you may have to re-run these commands in the future if 'new files' get 403 issues, in order to give correct permissions to the web server to keep being able to access files and folders that are created or copied in and aren't getting the www-data group set correctly.


(2) Give your owner read/write privileges to the folders and the files, and permit folder access to traverse the directory structure.

sudo chown -R USER /var/www/html/
sudo find /var/www/html -type d -exec chmod u+rwx {} +
sudo find /var/www/html -type f -exec chmod u+rw {} +

Replace USER in the first command with your own username!

We do three things here. First, we set your user to be the "Owner" of all the files and directories in /var/www/html. Next, we set read and write permissions on the folders, and permit you to access the folders to go into them (the +x item on the directory items). We then set all the files to have read/write permissions for the owner, which we just set.


(3) (Optional) Make sure every new file after this is created with www-data as the 'access' user.

sudo find /var/www/html -type d -exec chmod g+s {} +

This sets the "set gid" bit for the group on the directories. Files and folders created inside these directories will always have www-data as the group, permitting the web server access.


(4) (Optional) Final security cleanup, if you don't want other users to be able to see the data

We need your user to see the directories and files. We need the web-server to do so too. We may not want other system users (except root) to see the data. So lets not give them that access, and make it so only your user and the web server can see the data.

sudo chmod -R o-rwx /var/www/html/

NOTE: You will not have to re-run this at a later time, or edit the permissions for the 'other' category of permissions here. If the 'other' users can't get to /var/www/html/ (they don't have the necessary +x bit on /var/www/html to traverse the filestructure and directory structure, nor the +r bit to read the file lists), then the permissions on items underneath that directory for other users or groups isn't really going to matter too much.


There is a slightly less invasive solution to this, as well, though it's not guaranteed to work for all new files, nor is it guaranteed to work on all file systems, involving file access control lists. This lets you leave ownership of the files with www-data for things, but gives you effective owner rights, for all intents and purposes, even though you don't personally own the files.

This solution is a little less invasive, and lets you have a directory and all files within owned by www-data:www-data or root:www-data but also give yourself access. It uses Access Control Lists, which lets you have multiple users have permissions without setting up individual groups. This also lets the root or www-data system users own files, but also lets you add additional permissions on a case-by-case basis, and fine-tune permissions for certain users so they can read things but not edit, and such.

Assuming we're still working with /var/www/html/, and we don't want snooping users other than us and the system (and root of course) to see our data, we'll need to do the following things:

  1. Give ownership back to the webserver system user www-data.
sudo chown -R www-data:www-data /var/www/html
  1. Recursively give you read/write on the files, while giving other users (excluding www-data and root of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} \;
  1. Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding www-data and root) and set this as the 'default' ACL for new files in the directories.
sudo find /var/www/html -type d -exec setfacl -d -m u:YOURUSERNAME:rwx -m o::--- {} \;
  1. We also need to set the setgid bit for all directories, so that if you create a file the webserver can still access it as www-data via group permissions.
sudo find /var/www/html -type d -exec chmod g+s {} \;

And now you've got access to all the directories, and you didn't have to take access away from www-data which helps as the webserver can still create files everywhere as it needs to (such as PHP based frontends having their own cache directories and such needing to be created and written to for proper operation).

The only caveat: If you manually create new files, you need to chown them accordingly to give ownership to the webserver. That's a simple sudo chown www-data:www-data filename, and the access control lists should still let you have effective owner rights to the file.

There are multiple cases where I've had to do this as a sysadmin for some type of non-standard access without changing the owners of a given file. This works, but has its own headaches, as not every file system supports file access lists.

18
  • 2
    @AndréCarvalho +x to files would give executable permissions, and we don't want PHP files executed, necessarily, through the PHP command line or as an executable on the server itself - we want them processed by the PHP parser in the web server (and we don't need the PHP files to have +x for the PHP parser to read and process them). Directories need +x in order to permit traversal through the directories - that is, if a directory is not +x and I am not root, I can't get into the directory, which is the issue you had with Apache not working with your symlinks and your home directory.
    – Thomas Ward
    May 4, 2016 at 23:38
  • 1
    @AndréCarvalho www-data is a system group - it's not a group for standard users to be in.
    – Thomas Ward
    May 5, 2016 at 0:26
  • 1
    @JunaidQadirShekhanzai Impossible to provide since people's settings differ greatly from their environments they need, and many other factors. Such a 'shell file' would be impossible to produce given that there are optional components. I could try and make a Python script that could do this, but we still run into things like system restrictions, optional tasks, varying paths, etc.
    – Thomas Ward
    Feb 5, 2018 at 18:27
  • 1
    @T.Todua that's not what I said. I said that you should never run a site out of (read: from within) your "home" directory - that is, you should not run anything in /home/USER/... on a webserver. You've misread and misunderstood the meaning of the words I use. /var/www/* is a relatively 'safe' place to run websites out of because that's a dedicated folder/space for it. However, /var/www/html is NOT safe because that's written to by webservers on install and such, and leads to clobbering of important data (so use /var/www/SUBDIRECTORY with individual site subdirs instead)
    – Thomas Ward
    Jan 7, 2019 at 14:30
  • 1
    I've adjusted the wording for clarity.
    – Thomas Ward
    Jan 7, 2019 at 14:38
17

Excellent answer by Thomas ward https://askubuntu.com/a/767534/717860

You can do the all the recommended steps in just 3 commands instead of 8 commands:

3 commands:

sudo chown -R ubuntu:www-data /var/www
sudo find /var/www -type d -exec chmod 2750 {} \+
sudo find /var/www -type f -exec chmod 640 {} \+

do the same work as following 8 commands:

sudo chgrp -R www-data /var/www
sudo find /var/www -type d -exec chmod g+rx {} +
sudo find /var/www -type f -exec chmod g+r {} +
sudo chown -R ubuntu /var/www/
sudo find /var/www -type d -exec chmod u+rwx {} +
sudo find /var/www -type f -exec chmod u+rw {} +
sudo find /var/www -type d -exec chmod g+s {} +
sudo chmod -R o-rwx /var/www/
4

The whole idea of using symlinks to solve a permission issue is flawed and cannot work. The permissions that are shown for the symlink itself are mostly irrelevant, they cannot be used to circumvent the permissions of the "real" directory. Creating a symlink from /var/www/html/moodle to /home/andre/www/moodle/ doesn't circumvent the permissions for /home/andre/www/moodle/. Anyone, who wants to do stuff in /var/www/html/moodle can only do so, if he has got the necessary permissions for /home/andre/www/moodle/.

Your execution of sudo chmod -R 775 moodle/ actually did have an effect, but differently from what you thought it didn't change the permission of the symlink, but of the symlink target /home/andre/www/moodle/.

The 403 error you get in the webserver is probably because your webserver doesn't have the necessary permissions to enter /home/andre. This is not "an additional problem", but due to the same permission trouble.

So instead of using symlinks, you have to figure out permissions that allow you to edit the files and the web server to access them (or even edit them, that depends on the application). What exactly those permissions are, depends on your exact use case (your application and server configuration).

Generally I think it's a good idea that you own the files and have rw permissions, the web server has only read access to the files via the group permissions, and all other users have no access whatsoever.

A permission example (which might not work for your use case due to missing information):

andre@fermat:/var/www/html$ ls -al moodle/
total 0
drwxr-x--- 2 andre www-data 60 mai  4 16:20 .
drwxr-xr-x 3 root  root     80 mai  4 16:20 ..
-rw-r----- 1 andre www-data  0 mai  4 16:20 index.html

You can see that the directory has enough access for you as the owner to enter it and modify its content, the web server (in the group www-data) can enter and read. The files themselves are readable and writable to you (the owner) and readable to the web server (in the group www-data). All other users have no access whatsoever.

Again, please take this only as an example. The exact user/group of your web server depends on your configuration. And your application (moodle) might need different permissions, you have to consult its documentation.

4
  • Agreed, but this isn't too helpful if they don't know how to set the permissions correctly, and they'll run into other issues as well.
    – Thomas Ward
    May 4, 2016 at 14:17
  • @ThomasW.: Then the question of how to set the permissions properly should be a new question, including the necessary information, like the webserver configuration, the desired way of editing the files and the needs of the application.
    – mastov
    May 4, 2016 at 14:19
  • or written as a correct answer - which i'm doing now. You should alos never run anything out of /home/USER/ for a website either, it has access to a lot of other 'user' data if the web server isn't correctly patched or configured.
    – Thomas Ward
    May 4, 2016 at 14:19
  • @mastov Got it. You solve a lot of questions I had with your explanation. May 5, 2016 at 0:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .