Support

The permissions change only when you visit Akeeba Backup's Control Panel page, not when you take a backup. The permissions given are 0755 for directories and 0644 for file. Only the owner has write access. Everyone else has read only access. Given that these files are meant to be accessed over the web (they are CSS, Javascript and image files required to render the interface) I don't see what the problem is that needs fixing. If you use more restrictive permissions then the web server won't be able to serve the files, therefore you will not be able to use the component. Ergo, this is a non-issue that requires no fixing.

Some history: during the early versions of Akeeba Backup we discovered that a great deal of servers gave 0700 or 0600 permissions to these files and directories, making it impossible to use Akeeba Backup. We received a lot of angry support requests, some of them quite graphic (at one point it was stated that I do not know how to write code and I should take up knitting). We then added a big fat warning message which prompted the users to give the 0755/0644 permissions to make the component work. Sadly, people are completely incapable of reading. They saw that message and would post in frustration "What does this error mean?". When I told them to follow the instructions written on their screen, they would tell me that I was being a rude bastard that declined to help them *sigh* So, I decided to bite the bullet and have the component automatically fix the permissions. Magically, these angry support requests vanished overnight. So, this feature actually solves a very important problem, it does not create one.

I hope that explains what is going on :)

Hello Denise,

The lack of index.html files is intentional. They offer nothing to the security of your site. No matter if the index.html file exists or not, you are still able to access the files directly, as in http://www.example.com/media/com_akeeba/js/akeebaui.js. So, let's consider why we put index.html files in those directories. We want to prevent direct access to .php files in those directories, so that they can not be exploited as an attack vector by potential intruders.

The proper way to do that (the way Joomla! and yours truly implement it) is to have a defined(SOME_CONSTANT) or die() statement at the very top of the file, where SOME_CONSTANT is a PHP constant meant to be only defined in runtime. So, these files are indeed protected in all of my software.

Does index.html protect them? Not the slightest bit! If you know the URL to the file, you can access it. If the aforementioned line is missing, be there index.html or not, you are still in trouble.

Moreover, does placing an index.html file prevents an attacker from detecting that the component is installed? Not even the slightest bit and whoever said that should be tarred, feathered and hanged. If the component is not there and I try to access http://www.example.com/media/com_akeeba/js I will get a 404 error. However, if the index.html file is in there, I will get a seemingly blank page. Until I view the page source. Ta-da! There's HTML in there, so there is an index.html in that directory, ergo the component is installed. Therefore, index.html does not add to security.

So, why not include it anyway? When you have about 200 subdirectories in the component you need 200 index.html files. Let's consider how the component is being installed. Joomla! tries (in a single pageload!) to extract the ZIP archive and copy all the files to their final location on your site. If you are using the FTP layer (mandatory on most shared hosts) each file operation takes a lot of time. Having 400 more file operations (200 files extracted, then 200 files copied) makes the difference between successful installation and a timeout error.

You see, little things like that have been thought out very thoroughly. They seem trivial, but can make or break your experience trying to use the software.

Regarding the permissions change during backup, there is no such code in Akeeba Backup's backup engine. In fact, the backup engine is oblivious of the existence of the media directory! There is such code in Kickstart (when you are extracting an archive) if you are using its FTP mode. It has to do that for FTP to be able to overwrite existing files. To prove my point, please do the following experiment:
- Change the permissions of all files in the media/com_akeeba directory to 0644
- Check that they have indeed changed, by logging out of FTP and back in
- Visit Akeeba Backup's main page
- Log back in to your FTP and check the permissions of the files in media/com_akeeba. They should be 0644.
- Take a new backup and wait for it to complete.
- Log back in to your FTP and check the permissions of the files in media/com_akeeba. They should be 0644.

If any of those checks tells you that the permissions of the files are 0755 please tell me you PHP version, Joomla! version and whether you have enabled the FTP parameters in your site's Global Configuration.

Can you please check out the latest dev release? There was a typo in there that seems to have been causing this issue.

This build is about to be released as 3.3.b1 - I just have to integrate all the language files - so it is certainly not alpha. In fact, it's stable enough for me to use it on this site. The reason we call it "beta" is that we want more feedback on two optional features, System Restore Points and single-click update emails, before being able to call it "Stable" in good conscience.

However, if you do not want to install it on your client's site, that's cool. Just take a look at administrator/components/com_akeeba/models/cpanel.php.

Perfect! Thank you for your feedback and patience :)