I want to test my website in the real server, and I’m about to deploy it now. I was wondering about security issues, should I upload the files (via sftp) to /var/www/site/public_html as root, or should I create a user for the upload, and set the directory permissions to that user?
Thanks
Although you have accepted an answer here, the information provided is very wrong.
I appreciate that you will already know some of the things I'm going to say here, but since you accepted a very misleading answer there are some gaps in your understanding. Also not everyone reading this may have the same knowledge you do.
Yes, you should be careful with the root account and only use it where you have to. Only use it as it is intended to be used.
What you need is for the files to be readable by the webserver. And on a correctly configured device the webserver does not run as root. If you were to run
ps auxw | grep httpd
or
ps auxw | grep nginx
You would see at least 2 processes running. And actually one of them probably will be owned as root. That's because on the root user can start up a listening socket on a port number below 1024. That's a security thing. But having started the socket, this instance of the webserver then starts another instance of itself (running as a non-privileged user) to actually process requests.
On the box in front of me, I see....
root 20784 0.0 0.0 125116 1552 ? Ss 00:43 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 20785 0.0 0.0 125476 3252 ? S 00:43 0:00 nginx: worker process
www-data 20786 0.0 0.0 125476 3252 ? S 00:43 0:00 nginx: worker process
www-data 20787 0.0 0.0 125476 3252 ? S 00:43 0:00 nginx: worker process
www-data 20788 0.0 0.0 125476 3252 ? S 00:43 0:00 nginx: worker process
root 22579 0.0 0.0 14224 968 pts/1 SN+ 00:43 0:00 grep --color=auto nginx
So your content files need to be readable by the www-data user.
This account has even less privileges than the other account you describe. You can't login with this username. It is the opposite of the root account, it's a system or service account.
So how do you ensure you have the right permissions? You should have a regular account on the target you use to login (if you can ssh in or scp/sftp using the root account then your security is bad and should be fixed). Let's call this account auser. Once you have a shell on the system, then you should have the ability to become root via 'su' or 'sudo'. You can also transfer files using this account via sftp and scp (because you know that ftp is bad and have made sure there is no ftp server running on your host).
But this normal user account won't have permission to write to the directory containing the content (usually /var/www/html). So your first step in setting up the permissions is to change the ownership of this file to auser - and only root can do that. So...
sudo chown -R auser /var/www/html
Now /var/www/html should look something like this....
drwxr-xr-x 14 auser root 4096 Apr 5 19:52 /var/www/html
Looking at that first string of letters, the d means it is a directory, the rwx are the permissions for the owning user (read write and execute - but execute means something a bit weird for a directory - if a user should have any access to the directory then they need the execute permission). The first r-x indicates that the group has read and execute but not write. The second r-x means that every other account on the system (including www-data) has read and execute permissions on the directory.
The usual config for PHP, Python and Perl are that these are run as the webserver user (www-data). They do not need the executable permission bit set because they are not binaries (it would be required for pre-compiled languages like C and Go). There are models where the active content runs as different user than the webserver exist but are very rare and do not apply to your case.
But the default configuration on most Linux systems is to create files as ?rwx???--- (where the '?' represents stuff we're not that interested in. i.e. the "all other users" (or just "other" for short) don't get any permissions. And www-data can't read your files or cd into your directories. You could make sure you run....
chmod -R go+r /var/www/html
find /var/www/html -type d -exec chmod go+x {} \;
to fix this, but it's easier to just amend the config of your sshd to set the permissions appropriately. Typically you should be looking for the sftpserver definition in /etc/ssh/sshd_config and append '-u 002':
Subsystem sftp /usr/lib/openssh/sftp-server -u 002
Subsequently all transferred files will be -rw?rw?r-- and directories will be drwxrwxr-x
Yes, you could transfer the files as root / have the files owned by root and that does not compromise the security of your host. But allowing root to connect over ssh does compromise the security. That's why your sshd requires you to explicitly permit this to allow for edge cases - your sshd_config should contain...
PermitRootLogin No
Things get slightly more complicated when you need to allow multiple users to manage files. But we don't need to cover that now.
You will see mention on the the internet of chmod 0777 which gives everyone all permissions - never ever do this. Permissions are there to allow you to selectively share access.
So....
the root account is used to setup the initial permissions for a normal login account to control the files.
The webserver user should only have enough permissions to serve up the content (read-only).
Use a normal user account for managing files.
Related
Scenario:
bob owns directory x
bob has set permissions on x to 777
jim can't write to x. Why?
Actual output:
ls -la .pip/
total 12
drwxrwxrwx 2 user1 user1 4096 May 5 12:03 .
drwx------ 5 user1 user1 4096 May 6 11:34 ..
-rw-rw-rw- 1 user1 user1 2054 May 5 12:48 pip.log
sudo -S -p 'sudo password:' -u "apache" /bin/bash -l -c "mkdir .pip/monkey"
/bin/bash: /home/user1/.bash_profile: Permission denied
mkdir: cannot create directory `.pip/monkey': Permission denied
Ultimately I'm trying to pip install as apache user and that user is not allowed to write the install log, so the process fails. I need to write the log as apache user, but it lives in my user space. I could change the owner, but this process is supposed to work for any user, even new ones, so it's somewhat confusing what I'm supposed to do to achieve this.
UPDATE:
I understand from http://linux.die.net/man/2/path_resolution that it is the fact that apache does not own user1's home directory, so the directory search won't work. Is this the case?
Disclaimer: At the time this answer was composed, the question did not clearly identify working directories. If assumptions documented in the answer are incorrect, the folders mentioned in the answer may need to be adapted accordingly.
It appears that the question asks why user apache cannot operate under:
/home/user1/
It also appears that /home/user1 may have permissions set to drwx------ as these permissions are typically used to help secure private data that can accumulate in the root of the user's home directory.
If the above is true, then it is normal for apache to not be able to work under /home/user1/ because it does not have traversal rights to /home/user. Such rights can be added in various ways. The simplest, but not particularly safe way to do it is something like:
sudo chmod o+x /home/user1
It would then be possible for /home/user1 sub-folder permissions to be tightened and loosened to fit the need. It would be better to use group permissions than world permissions, but you should probably create a special group for this purpose rather than making apache a member of the user1 group. An even better solution would be to use an ACL that grants apache traversal rights to /home/user1 without opening the user's home directory up to a wider audience.
Be careful. Loosening permissions with the aforementioned command can give all users on the box access to sub-directories of the user's home directory if their permissions are not suitably tight.
Note: Security mechanisms on some systems might get annoyed by loosening of user home directory permissions and interfere with manual overrides. This could happen, for example, on a distribution that has msec configured to a relatively high security level. Without more detail given about the system configuration, it is somewhat difficult to anticipate potential problems. For example, unless an exception has been made for particular file system areas, on an msec managed system with high security set, msec will periodically rewrite directory permissions that it monitors if it does not consider the permissions compatible with the configured security level.
On a Ubuntu machine I've setup a SVN repository, served with Apache.
All the SVN repository folders and subfolders (located under /var/svn/repos/) belongs to www-data user and group:
drwxr-xr-x 7 www-data www-data 4096 gen 21 10:38 software_repository
www-data is the Apache user.
Next I've a cron job that makes a nightly svnadmin dump of the repository, using my home user, let's say john_doe (joining the www-data group too). svnadmin dump command (and more...) are contained in a sh file called by the crond.
During cron job or launching it manually using user john_doe I get:
svnadmin: E160052: Revprop caching for '/var/svn/repos/sw/software_repository/db' disabled because SHM infrastructure for revprop caching failed to initialize.
svnadmin: E000013: Can't open file '/var/svn/repos/sw/software_repository/db/rev-prop-atomics.mutex': Permission denied
Because of Permission denied error, I've run the same sh script prepending sudo command, and everything works fine.
So, we have 2 possibilities:
Understand where the SVN error come from.
Change permissions in a correct way for the john_doe user, used by cron.
For point #1 I've done some Google search but I've found nothing...
For point #2, I think the correct way is not to set all permissions (recursively) of the group www-data to all SVN folders and subfolders. What it could be done is to share permissions on SVN folders between www-data user and john_doe. Or give to the www-data group the same permissions (recursively) of the www-data user. Or something else, but for both solutions I've no idea of the correct command or configuration setting.
Solved running command:
chmod -R g=u software_repository
This fix is for solution 2. By the way I've no clue where the SVN errors come from...
I have moved my website from Godaddy to a VPS server. I'm new to Linux so I followed some tutorials online but still confused about some problems.
I use SSH to log on my server as user adam. In order to run the PHP properly, I have to set 755 permission to /var/www and change the owner of this folder to www-data. But that means I don't have permission to write files in this folder even if add user adam to the group www-data. And I cannot upload webpages onto this folder using FTP which is very annoying. (Currently I have to type su to switch to root and then modify these files with nano)
I know setting 777 is a solution but it may cause some safety concerns so I'm looking for a better solution.
drwxr-xr-x 8 www-data www-data 4096 Jul 24 21:36 www
Every number of permisson is composed as follows
4: read
2: write
1: execute
So if you add them you get the permission. By example 7 means all the permisons and 6 means read and write.
The first number of 755 is for the owner, the second for the group's users and the third for other users.
Then 755 means rwxr-xr-x it is the owner can read wirte and execute, but the group member can't write.
If you want to solve this you can change the privileges to 775 then it will be change to rwxrwr-x
Or you can add www-data as a secondary group to adam and set a setgroupid www-data fro /var/www
I have a bash script to sync a Zendframework site between two servers, but for some reason one file doesn't get the correct owner/group. Since the file then becomes unreadable by apache the site goes down on that server.
On the first server I have the following file:
-rwxrwx--- 1 monit www-data 4184 2012-03-14 05:39 application.ini
This should be exactly the same on the second server since both the user monit and the group www-data exists there to, but this is not the case as seen below.
-rwxrwx--- 1 monit monit 4184 2012-03-14 05:39 application.ini
This file is the only one affected. All other files gets the correct permissions, owners and groups. The rsync command is as follows
rsync -az --delete --stats --include="document_root/.*" --exclude=".*" SERVER1 SERVER2
rsync is version 3.0.3, Server 1 is a Ubuntu 9.04 and Server2 is Debian 5.0
At the moment the problem is circumvented by setting the permission on the original file to -rwxrwxr--. The synced file will still have the wrong group, but is at least readable.
Check that monit user is in www-data group on the target server.
Try rsyncing the problematic file only, while running rsync on the target server and add one or more -v options, then look at the output:
$ groups monit |grep www-data
$ rsync -avv source_host:path/to/application.ini ./application.ini
I want to create a file in a directory owned by the staff group which I am a member of. Why can I not do this?
bmccann#bmccann-htpc:~$ ls -l /usr/local/lib/R/
total 4
drwxrwsr-x 2 root staff 4096 2010-07-31 16:21 site-library
bmccann#bmccann-htpc:~$ id -nG bmccann
bmccann adm dialout cdrom plugdev staff lpadmin admin sambashare
bmccann#bmccann-htpc:~$ touch /usr/local/lib/R/site-library/tmp
touch: cannot touch `/usr/local/lib/R/site-library/tmp': Permission denied
Did you logout and log back in after making the group changes? See:
Super User answer involving touch permissions failure
I had the same issue, check if the folder has any more ACL rules or not!
If you can see + (plus sign) when you list folder, that means it has special access rules. For example:
[user_in_apache_group#web02 html]$ ls -l
total 16
drwxrwxr-x 16 apache apache 4096 Sep 4 13:46 ilias
drwxrwxr-x+ 15 apache apache 4096 Sep 4 13:46 ilias5
View the permission:
[user_in_apache_group#web02 html] getfacl ilias5
# file: ilias5
# owner: apache
# group: apache
user::rwx
user:user_in_apache_group:r-x
group::rwx
mask::rwx
other::r-x
So that means my user (user_in_apache_group) has no write permission for that folder.
The solution is what #techtonik said, add write permission for user:
[user_in_apache_group#web02 html]$ sudo setfacl -m u:user_in_apache_group:rwx ./ilias5
Check permission again:
[user_in_apache_group#web02 html] getfacl ilias5
...
user:user_in_apache_group:rwx
...
Hope it helps. ;)
Why can't Linux user edit files in group he is a part of?
I am using Ubuntu 12.04 and had the same problem where a user cannot write to a file to whom he is allowed group access to. For example:
whoami //I am user el
el
touch /foobar/test_file //make a new file
sudo chown root:www-data /foobar/test_file //User=root group=www-data
sudo chmod 474 /foobar/test_file //owner and others get only read,
//group gets rwx
sudo groupadd www-data //create group called www-data
groups //take a look at the groups and see
www-data //www-data exists.
groups el //see that el is part of www-data
el : www-data
Restart the terminal now to ensure the users
and groups have taken effect. Login as el.
vi /foobar/test_file //try to edit the file.
Produces the Warning:
Warning: W10: Warning: Changing a readonly file"
What? I've done everything right why doesn't it work?
Answer:
Do a full reboot of the computer. Stopping the terminal isn't enough to fix these problems.
I think what happens is apache2 also uses the www-data group, so the task was somehow preventing the users and groups from being enforced correctly. Not only do you have to logout, but you have to stop and restart any services that use your group. If a reboot doesn't get it, you've got bigger problems.
Use Linux ACL (access control lists) - it is more fine-grained version of permission system,
setfacl -R -m 'group:staff:rwx' -m 'd:group:staff:rwx' /usr/local/lib/R/
This sets both active rights for directory and default rights for anything created within.
This fails to work without relogin if you've just added yourself to the staff group, but you may set the permission only for yourself for the current session.
I had an issue when a user could not access the /foo/bar/baz directory even when he had permissions because he did not have an access to the bar directory.
Maybe your hard disk is full. use this command to check out the "/dev/..." rows.
df -h
Check if your parent directory have permission before you add content to that file
sudo chmod -R 777 /yourDir/file.log