I used Joomlapack to build a .jpa backup. Installed Kickstart and the backup on a new server. When I ran kickstart it created my site, but the permissions of all files are 755, not just the directories. How do I fix this?
#3461 755 permissions on everything
Posted in ‘UNiTE and Remote CLI’
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
PHP version
n/a
Tool
UNiTE
Tool version
n/a
Latest post by user1615 on Sunday, 08 February 2009 23:42 CST
Thursday, 15 January 2009 00:12 CST
user1923
Thursday, 15 January 2009 03:00 CST
user736
you should be able to go in and say all files set to this and all directories set to this. i know filezilla client you can do this
Monday, 19 January 2009 17:40 CST
user1615
I also found that all my files following a restoration were all set to 755 instead of their original settings at 644, 400 etc. Having to chmod all the files is very time consuming when you have several websites to administer. Is it really necessary for the files to be 755 following a restoration. Could they not be automatically chmoded to their original settings?
I have also noticed that on sites where i have certain files set to e.g. 400 or 444, the kickstart restoration fails to work properly. I had to clear the entire file system for that particular site, manually copy/upload across the backup zip file and kickstart.php file and then perform the restoration without having to overwrite any existing files.
It would be appreciated if Nicholas could please check this out. Otherwise i am very satisfied with Joomlapack as the backups particularly save me heaps of time. Thank you for this great component.
I have also noticed that on sites where i have certain files set to e.g. 400 or 444, the kickstart restoration fails to work properly. I had to clear the entire file system for that particular site, manually copy/upload across the backup zip file and kickstart.php file and then perform the restoration without having to overwrite any existing files.
It would be appreciated if Nicholas could please check this out. Otherwise i am very satisfied with Joomlapack as the backups particularly save me heaps of time. Thank you for this great component.
Tuesday, 20 January 2009 20:16 CST
nicholas
Akeeba Staff
Manager
There is always a rational explanation for this. If your site is set up correctly, 0755 permissions should be secure enough for normal operation. Having 0400 permissions seems a bit too restrictive and useless. The owner will be able to write to the files anyway, so be it 0400, 0600 or 0700 it's the same from a practical standpoint.
If you used FTP to upload the files, having 0644 permissions is rational, but so is 0655 (the exec bit doesn't harm on properly configured hsots) and - applying the idea above that the owner's bits really have no effect on the PHP level - 0755 is the same.
There is also another reason to use 0755 permissions: PHP would create files with 0700 permissions, which will render the site inoperable if you use the FTP mode to extract the archive. 0755 permissions was the best compromise.
Another issue is that ZIP doesn't store the permissions bits, so we couldn't restore these permissions. Even though JPA does store the permissions bits, it can't really know who's the owner of the file. It's one thing to have 0700 files owned by Apache and another thing to have 0700 files owned by the FTP user. In the former case they'll be accessible by visitors, in the latter they will not be accessible by visitors - or even Joomla!'s backend - at all! So, I had to figure out a best compromise.
As far as Kickstart's inability to overwrite 0400 or 0444 files is concerned, yes this is true. If you use the FTP mode it will try to change these permissions, but FTP doesn't allow permissions modifications unless these files are owned by the FTP user and they have the write bit set. Obviously 0400 and 0444 do not, so it can't change permissions and won't be able to overwrite them. It's an OS and FTP server restriction we can't circumvent.
Your best bet for site security is to use Kickstart's FTP mode to extract files and apply Joomla!'s FTP mode without storing the FTP password. Using this trick, the only way to write to configuration files would be to supply the FTP password on the Joomla! backend each and every time you are modifying configuration files. Secure and easy, without messing with permissions. Do note that modifying permissions was a necessary workaround for Joomla! 1.0.x because it lacked an FTP layer.
If you used FTP to upload the files, having 0644 permissions is rational, but so is 0655 (the exec bit doesn't harm on properly configured hsots) and - applying the idea above that the owner's bits really have no effect on the PHP level - 0755 is the same.
There is also another reason to use 0755 permissions: PHP would create files with 0700 permissions, which will render the site inoperable if you use the FTP mode to extract the archive. 0755 permissions was the best compromise.
Another issue is that ZIP doesn't store the permissions bits, so we couldn't restore these permissions. Even though JPA does store the permissions bits, it can't really know who's the owner of the file. It's one thing to have 0700 files owned by Apache and another thing to have 0700 files owned by the FTP user. In the former case they'll be accessible by visitors, in the latter they will not be accessible by visitors - or even Joomla!'s backend - at all! So, I had to figure out a best compromise.
As far as Kickstart's inability to overwrite 0400 or 0444 files is concerned, yes this is true. If you use the FTP mode it will try to change these permissions, but FTP doesn't allow permissions modifications unless these files are owned by the FTP user and they have the write bit set. Obviously 0400 and 0444 do not, so it can't change permissions and won't be able to overwrite them. It's an OS and FTP server restriction we can't circumvent.
Your best bet for site security is to use Kickstart's FTP mode to extract files and apply Joomla!'s FTP mode without storing the FTP password. Using this trick, the only way to write to configuration files would be to supply the FTP password on the Joomla! backend each and every time you are modifying configuration files. Secure and easy, without messing with permissions. Do note that modifying permissions was a necessary workaround for Joomla! 1.0.x because it lacked an FTP layer.
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!
Sunday, 08 February 2009 23:42 CST
user1615
Thanks for this explanation. I have recently used GuardXT for checking site security and it seems to work really well. One great feature of this component is that you can quickly see the folders and files that do not have their permissions set correctly and easily reset them with just one click. In the case of a typical post Joomlapack restoration, this feature allows you to reset all permissions to their correct status in just seconds. This is very much faster than using Filezilla even though Filezilla works well also. I have found by applying the suggested security methods as suggested in Joomla security docs + GuardXT, my sites are now much better protected. However we must of course always be vigilant. Cheers.