Support

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it to your server and post a link to it.

Description of my issue:
Today I found out that the File permission of to Akeeba Logfile is set to 666 instead of 644.

I read a lot of posts where you are saying it is a hosting setup. With the hoster, I did some test. We made the following PHP script and run it.

<?php

$file = 'test.txt';
// Append a new person to the file
$current = "TESTFILE\n";
// Write the contents back to the file
file_put_contents($file, $current);

?>

The result of the file was:

-rw-r--r-- 1 test.xxxxx.nl psacln 168 Oct 18 10:52 test.php
-rw-r--r-- 1 test.xxxxx.nl psacln 9 Oct 18 10:58 test.txt

This seems that the server is handling it correctly. What I did:

After the backup, we upload it to a remote FTP Server. I guess this should not impact the log file permission.

Please, advice what to do or where the issue is. Of course, it is not a big issue (it is in a save directory), but it isn't nice.

Best regards,

Arjen Schrijvers

I don't think it is the server configuration. If I did the test above (script) and run it, it will make a file called text.txt with permission 644. This means the server is good.

So I really think it is something in Akeebaa backup that is messing up the persmissions.

Please, can you do a test on your site and verify it?

Best regards,

Arjen Schrijvers

18th october is not several days. Thet test.txt was made directly after you told me it could be an servicer configuration issue. So that should not be the issue.

I search in the akeeba code for the PHP command chmod. I found several ones and see that they change hardcoded the permissions of files. Below you find a list of these files. I

administrator/components/com_akeeba/BackupEngine/Util/Logger.php: @chmod($this->logName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Jpa.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Jpa.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Zipnative.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/BaseArchiver.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Jps.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Zip.php: chmod($this->_dataFileName, 0666);
administrator/components/com_akeeba/BackupEngine/Archiver/Zip.php: chmod($this->centralDirectoryFilename, 0666);
administrator/components/com_akeeba/AliceEngine/utils/logger.php: @chmod(AliceUtilLogger::$logName, 0666);
administrator/components/com_admintools/engine/Util/Logger.php: @chmod($this->logName, 0666);

I guess logger.php is writing the files with permission 666. Is there a reason why files are save with 666? Could this be the reason of 666?

Best regards,

Arjen Schrijvers

Hello Davide,

Ok, apologise excepted.

Strange standpoint from Akeeba that the agree to support 666 to support bad host.

In my opinion, a bad host should not support at all.

Better that Akeeba has a default value of 644 and in case there is a ' bad' host, the bad host can change it in the configuration settings of Akeeba.

Why am I making a point of it? My external security check is yelling that the permission is not good. And they are right. Although I know it is not directly harmful, my customer get scary if he sees such message.

Of course I can change it in the code of Akeeba, but this means after update changes are gone. Has akeeba the plan to change the permission or is akeeba leaving it as it is now?

Thanks letting us know Davide.

Ik will turn the login on Akeeba off. Besides it saves disc space, I'm sure I'm leaking non-information about the backup.

If I'm turning login off, is it then still making an empty log file?

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.