- b2evolution CMS User Manual
- Installation / Upgrade
- New Installation
- Installing on a Remote Server
- UNIX Directory and File Permissions
UNIX Directory and File Permissions
What are file permissions?
UNIX/Linux file permissions are a way to control who can read and/or write files on your hosting account. On a shared hosting server, this will (on serious web hosting providers) prevent another user from modifying your website!
When you upload files to your webserver by FTP, those files are saved on the server with some specific access permissions. Typically, everyone will be able to "read" the files and subdirectories, that is: view them through the webserver, but only you and you alone (when you log into the FTP server) will be able to "write" to these files/subdirectories. That means only you will be able to modify the files and/or create new files and sub-directories.
Why should I care?
If you are lucky, your web hosting provider has all the file permissions set up in such an effective way that you will never need to care. However, if you get a "file permission error" at some point, here is why… and how to fix it…
For some specific actions, b2evolution will need "write" access to some files. For example, b2evolution will need to write new files when you use b2evolution to upload an image or when b2evolution wants to write a cached page to disk for improving future performance. The problem is: b2evolution is not you. More specifically: the PHP process that runs b2evolution is not you! And the PHP process may not have permission to write files as you do.
Thus you may need to change the permissions on some files and subdirectories in order to allow b2evolution to write there and perform the requested actions.
Why wasn’t this done automatically on install?
Because if PHP has no permission to write to a file, then PHP has no permission to give itself write permission either. That makes sense from a security perspective, doesn’t it?
You should actually blame this on your hosting admin who decided PHP would not be allowed to write to files by default. On shared hosts, the hosting company should actually be using mod_suphp
in order for your PHP scripts to run under your own user account, thus enforcing the best possible isolation from other users on the same server, and resolving all file permission issues at the same time. The single fact that you run into file permission issues on a shared host is a bad sign regarding the security setup of your host. (If you run your own private/dedicated server though, this is normal and will generally lead to better performance.)
How do I change file permissions?
First, you may need or wish to understand how file permissions work. Most webservers run some variant of UNIX/Linux. On these systems, file permissions can be changed via the chmod
on the command line.
There are several possible ways to change file permissions on a UNIX/linux webserver:
- with the "change permissions" option of your FTP client program such as FileZilla (see your FTP documentation)
- with the file manager of your web hosting control panel (see your host documentation)
- by issuing
chmod
shell commands (if you’re not familiar with shell access, use one of the above)
What files/subdirectories do need specific permissions?
/blogs/media/ sub-directories
All subfolders of /media
should be writable by b2evolution in order for uploads to work.
The exact permissions you want to give to those folders depend on your web host setup. You may want to give full access "777" but that may not be very secure. Ask your host’s technical support for details specific to your hosting plan. As a rule of thumb, if you have a problem, you should probably try to enable group write permissions first (typically "g+w" or "774").
If you have shell access, the command to grant group write access, recursively, on all sub-directories and files of the /media folder is this:
<!– codeblock lang=shell line=1 –><pre class="codeblock">chmod -R g+w /path/to/blogs/media
<!– /codeblock –>
/blogs/cache/ sub-directories
This is where b2evolution will write static cached pages for improved performance.
This requires exactly the same permissions as the media directories above.
/blogs/conf/_basic_config.php
This file is ‘'’critical”’, because it includes your database password! You want to protect that password from other users as much as possible.
This file needs to be writable by the webserver ‘’during installation'’, unless you want to manually edit the file.
This file should have the most restrictive permissions possible: "600" would be the best if your server setup allows it..
If you are not sure, try it in the following order: ‘"600", "660" and (only if necessary) "666".
After installation the file does not need to be writable anymore. At that time you may lower permissions to, in order of preference: "400", "440" or (only if necessary) "444".
Other
Allow creation of blog stub files from the admin interface or to generate static pages for your blogs:
<!– codeblock lang=shell line=1 –><pre class="codeblock"> chmod g+w path/to/blogs
<!– /codeblock –>
If you want to use the template editor for the custom skin:
<!– codeblock lang=shell line=1 –><pre class="codeblock"> chmod -R g+w path/to/blogs/skins/custom
<!– /codeblock –>
FTP Clients
Contrary to popular belief, when your FTP client cannot change the permissions of a file, it is not an issue with the FTP client. It is an issue with the permissions themselves. For example: you don’t own the file you want to change permissions for. If you can’t figure out how to change the permissions of a given file, contact your hosting tech support. That is what they are here for ;)
2 comments
Comment from: fplanque
@gr8dude Something similar is already included in the sample .htacess file that comes the media directory. But you can definitely add your code too.
Is it reasonable to further tighten security by adding another .htaccess file to the /media directory, with something like
The problem is that I somehow found myself hacked, with a file called `thumbs_up.php` in my /media directory, if I opened it - it was a file manager that allowed access to me directories.
With such a .htaccess file in place - executing PHP scripts (or other flavours of scripts) would be prohibited.
1. Is this a good idea?
2. Does it have side effects?
3. How about including it in b2evo out of the box?