Support

Akeeba Backup for Joomla!

#8907 /media file permissions change during backup

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Friday, 24 June 2011 10:17 CDT

user39887
Mandatory information about my setup:

Have I searched the forum before posting? Yes
Have I read the Troubleshooting Wizard before posting? Yes
Have I read the documentation before posting? Yes
Joomla! version: 1.5.23
PHP version: 5.2.6
MySQL version: 5.0.92-community
Host: Hostgator
Akeeba Backup Professional version: 3.2.7 Pro

Have noticed that all Akeeba files in /media/com_akeeba are changed to 755 permissions when a backup is run. Are there plans in place to fix this?

nicholas
Akeeba Staff
Manager
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 :)

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user39887
Nicholas,

While I appreciate your previous frustrations re file permissions, I think you have missed my point.

I *know* that folders should be 755 and files should be 644. What I am saying is that if I run a backup from the control panel, all of the FILES within the /media/com_akeeba subdirectories are changed to 755 instead of remaining 644.

Also, each of the subdirectories are lacking the index.html file.

Respectfully,
Denise

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user39887
I had already performed those steps (of checking the file permissions before and then after performing a backup) prior to reporting the issue. So, yes, the files are being changed to 755 during the backup process.

PHP and Joomla versions were given in my first post of this thread.

FTP is enabled in the Global Configuration, although I do not store the username and password in the configuration file.

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

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user39887
I'll check out the latest release, but I can't afford to put an alpha version on this client's server. If you'd like to share the filename that contained the typo, it would be appreciated.

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user39887
Thanks for pointing out the file. Made that change and all working as expected.

nicholas
Akeeba Staff
Manager
Perfect! Thank you for your feedback and patience :)

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!