Permissions problems with /var/www/html and my own home directory for a website document root
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 though in 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 thats 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?
permissions apache2 webserver moodle
add a comment |
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 though in 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 thats 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?
permissions apache2 webserver moodle
add a comment |
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 though in 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 thats 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?
permissions apache2 webserver moodle
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 though in 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 thats 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?
permissions apache2 webserver moodle
permissions apache2 webserver moodle
edited Mar 19 '17 at 9:02
Zanna
50.3k13133241
50.3k13133241
asked May 4 '16 at 13:53
André CarvalhoAndré Carvalho
140137
140137
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
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
:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- 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.
(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 bewww-data
.
(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:
- Give ownership back to the webserver system user
www-data
.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-data
androot
of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} ;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-data
androot
) 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::--- {} ;
- We also need to set the
setgid
bit for all directories, so that if you create a file the webserver can still access it aswww-data
via group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} ;
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.
1
@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 '16 at 23:38
1
@AndréCarvalhowww-data
is a system group - it's not a group for standard users to be in.
– Thomas Ward♦
May 5 '16 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 '18 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 at 14:30
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
|
show 9 more comments
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.
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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
add a comment |
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/
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f767504%2fpermissions-problems-with-var-www-html-and-my-own-home-directory-for-a-website%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- 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.
(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 bewww-data
.
(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:
- Give ownership back to the webserver system user
www-data
.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-data
androot
of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} ;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-data
androot
) 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::--- {} ;
- We also need to set the
setgid
bit for all directories, so that if you create a file the webserver can still access it aswww-data
via group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} ;
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.
1
@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 '16 at 23:38
1
@AndréCarvalhowww-data
is a system group - it's not a group for standard users to be in.
– Thomas Ward♦
May 5 '16 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 '18 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 at 14:30
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
|
show 9 more comments
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
:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- 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.
(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 bewww-data
.
(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:
- Give ownership back to the webserver system user
www-data
.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-data
androot
of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} ;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-data
androot
) 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::--- {} ;
- We also need to set the
setgid
bit for all directories, so that if you create a file the webserver can still access it aswww-data
via group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} ;
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.
1
@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 '16 at 23:38
1
@AndréCarvalhowww-data
is a system group - it's not a group for standard users to be in.
– Thomas Ward♦
May 5 '16 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 '18 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 at 14:30
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
|
show 9 more comments
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
:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- 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.
(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 bewww-data
.
(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:
- Give ownership back to the webserver system user
www-data
.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-data
androot
of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} ;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-data
androot
) 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::--- {} ;
- We also need to set the
setgid
bit for all directories, so that if you create a file the webserver can still access it aswww-data
via group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} ;
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.
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
:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- 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.
(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 bewww-data
.
(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:
- Give ownership back to the webserver system user
www-data
.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-data
androot
of course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} ;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-data
androot
) 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::--- {} ;
- We also need to set the
setgid
bit for all directories, so that if you create a file the webserver can still access it aswww-data
via group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} ;
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.
edited Jan 7 at 14:37
answered May 4 '16 at 14:22
Thomas Ward♦Thomas Ward
43.7k23120173
43.7k23120173
1
@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 '16 at 23:38
1
@AndréCarvalhowww-data
is a system group - it's not a group for standard users to be in.
– Thomas Ward♦
May 5 '16 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 '18 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 at 14:30
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
|
show 9 more comments
1
@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 '16 at 23:38
1
@AndréCarvalhowww-data
is a system group - it's not a group for standard users to be in.
– Thomas Ward♦
May 5 '16 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 '18 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 at 14:30
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
1
1
@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 '16 at 23:38
@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 '16 at 23:38
1
1
@AndréCarvalho
www-data
is a system group - it's not a group for standard users to be in.– Thomas Ward♦
May 5 '16 at 0:26
@AndréCarvalho
www-data
is a system group - it's not a group for standard users to be in.– Thomas Ward♦
May 5 '16 at 0:26
1
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 '18 at 18:27
@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 '18 at 18:27
1
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 at 14:30
@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 at 14:30
1
1
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
I've adjusted the wording for clarity.
– Thomas Ward♦
Jan 7 at 14:38
|
show 9 more comments
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.
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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
add a comment |
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.
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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
add a comment |
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.
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.
edited May 4 '16 at 14:22
answered May 4 '16 at 14:16
mastovmastov
1789
1789
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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
add a comment |
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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
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 '16 at 14:17
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 '16 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 '16 at 14:19
@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 '16 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 '16 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 '16 at 14:19
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
@mastov Got it. You solve a lot of questions I had with your explanation.
– André Carvalho
May 5 '16 at 0:30
add a comment |
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/
add a comment |
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/
add a comment |
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/
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/
edited Aug 10 '18 at 22:52
j08691
1035
1035
answered Jul 26 '17 at 10:39
vipin mehtavipin mehta
212
212
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f767504%2fpermissions-problems-with-var-www-html-and-my-own-home-directory-for-a-website%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown