When running a web server you might have come across permission problems when uploading files to the document root. Files are owned by the upload user, apache can read them, but upload and modification via the web front-end fails and much more. The reason is the permission and ownership structure in Linux, but how to solve this mess?
To solve this you need to understand the Linux File Permission concept. With this understanding, the problem is more clear as well. Uploaded files get the owner and group of the uploading user, and they get the default permissions as well. These permissions are defined by the umask. Having the default umask will mean that these files will have read and write permission for their owner and read only permission for group and other.
Create the upload user
Knowing the reason for the problem with the permission and owner, we can create an upload user that should not cause this problem:
$ USER_PASSWORD=`perl -e 'print crypt("TheUserPassword", "password"),"\n"'` $ useradd --no-user-group -g apache -G ssh_login_group -p $USER_PASSWORD web_content_user
This will create a new user on your system with the user group of the webserver. With this command a secondary group “ssh_login_group” is also assigned to the user. This is done to secure ssh access as described in Secure SSH server access.
The user having the same group as the webserver will cause all uploaded files and directories to get the group of the webserver. This only solves one part of the problem as the default permission of uploaded files only allows read access to the group.
Change the default permissions for uploaded files
The permission given to a file or directory is defined by the umask. A umask of 022 is usually defined by default. This results in a file permission of rw-r–r– (644) on new files. To let the webserver access and modify the files the group permission needs to be set to allow read and write. This is done by defining the umask 002:
$ echo "umask 002" >/home/web_content_user/.bash_profile
This line in the bash configuration will define the umask as 002 which will result in rw-rw-r– (664) permission for new files. This permission together with the group beeing the same as the webserver will solve the problem. New files uploaded by our new user will have the group of the webserver and the webserver group will have read and write permission to the files and directories uploaded.
To make it more comfortable to navigate I decided to create a symbolic link in the upload user’s home directory pointing to the document root of the webserver:
ln -s /var/www/html/ /home/web_content_user/html
With this link you can easily navigate to the document root of the webserver and upload your content.
As the /var/www/html directory is usually owned by root, you might not be allowed to upload anything directly into the /var/www/html directory. You might anyway want to create subdirectories for the different virtual hosts you might have. Those subdirectories should be owned by the webserver or the upload user to allow file uploads by the user we created above.
Set the umask for the webserver
The following setting will also set the umask for the user apache is running as. With this configured, all files uploaded or created by the webserver user will use the umask defined here. Umask will not force the permission flags on files such as website scripts that explicitly set the file permission and this may result in files having different permissions than you might expect:
echo >>/etc/sysconfig/httpd echo "# Set umask for the apache user" >>/etc/sysconfig/httpd echo "umask 002" >>/etc/sysconfig/httpd
Another hint worth mentioning is that a restart of apache will not apply the change. It is necessary to stop and then start apache for this setting to take effect:
/etc/init.d/httpd stop /etc/init.d/httpd start
With the webserver running with the umask set to 002, all files and directories should get the read and write permission flag for the file’s user and group. The owner of the file would still not be the user configured to upload the web content, but this user would be allowed to fully manage these files.
Read more of my posts on my blog at http://blog.tinned-software.net/.