Support

Akeeba Backup for Joomla!

#40850 Akeeba Kickstart Pro 8.0.5 blocks itself with 0666 permissions assignment on extraction

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
5.0.1
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Friday, 21 June 2024 09:54 CDT

AllenK

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 10MiB, please upload it on your server and post a link to it.

Just giving a heads-up. I went to restore a site backup today with Kickstart Pro 8.0.5. Trying to run the restoration script resulted in a 403 error even though no .htaccess file existed in the root, and the site was being restored to a new root folder peer to public_html.

I tried restoring with Kickstart Pro 8.0.4, and everything went great.

When I compared file permissions on both versions of the extracted kickstart, I saw that 8.0.4 assigns 0644, where 8.0.5 assigns 0666. Changing the file permissions to 0644 allowed 8.0.5 to run fine.

 

Thanks for such an awesome tool, BTW. It's save my A** many times.

nicholas
Akeeba Staff
Manager

That would not be possible, on account of the code having to do with file extraction finalization (where permissions are set) having literally not been touched in two years.

If you read the CHANGELOG, the only changes between 8.0.4 and 8.0.5 are:

Remove CURLOPT_BINARYTRANSFER. This flag did absolutely nothing in PHP for nearly 15 years, therefore it's time to remove it. Only used in Kickstart Pro when retrieving files from remote storage.

Clear PHP filestat cache before trying to write to a file. We noticed that cPanel-based hosts fail to extract the backup archive when you're using recent versions of PHP compiled after the beginning of May 2024. A change in cPanel's patching of PHP made it so that a manual clearstatcache() is now required before writing to files. This merely tells PHP "Please forget what you remembered about files existing, and their sizes. Next time I ask you to open a file, ask the Operating System if the file exists and whether it's readable and writeable".

This will NOT change the permissions an extracted file is created with. We literally just do

$outfp = @fopen($this->fileHeader->realFile, 'w');

We do not set permissions here. PHP creates the file using the default umask.

After we are done writing to the file, we have the post-processing. Here, two things can happen:

  1. If "Restore file permissions" was checked: Kickstart restores the file / folder permissions as they were recorded in the backup archive at backup time.
  2. If "Restore file permissions" was NOT checked: Kickstart applies 0644 permissions to files, and 0755 permissions to folders.

This part of the code has NOT changed since August 2014 – ten years ago.

So, what I suspect happened is that you accidentally checked the "Restore file permissions" box. The permissions of the files were the very much not recommended 0666 which is why you had a problem. Going back a version did nothing, really. The only difference is that this time you didn't check the box, hence Kickstart fell back to its default behaviour of giving files 0644 permissions.

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!

AllenK

Hi,

Ticking the box was not relevant since Kickstart.php would not open at all due t a 403 error since extracting (unzipping) the kickstart zip in cPanel file manager resulted in the kickstart files themselves having 0666 permissions upon extraction. Subsequently renaming kickstart.php and attempting to initiate restore would not open due to 403 error.

When I extracted kickstart 5.0.4 in cPanel file manager, it extracted kickstart files with 0644 permissions. Renaming and running kickstart worked just fine from the extracted 5.0.5 files.

I don't know why the 5.0.5 kickstart zip package itself unzipped with different permissions than when unzipping kickstart 5.0.4. See attached.

 

nicholas
Akeeba Staff
Manager

OK, now I understand what you are saying. I am not sure why that was the case. ZIP files don't even store UNIX permissions.

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!

AllenK

It seemed weird to me as well. That's why I forwarded it as an odd behavior you might want to know about.

Have a great weekend!

nicholas
Akeeba Staff
Manager

I see that InfoZIP does behave weirdly under some conditions. I am adding a workaround for the next version. Thank you and have a great weekend!

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!