Akeeba Backup for Joomla!

Monday, 11 July 2011 06:23 CDT

user39436

Hello,

---------------------------
addendum:
The steps I have just done. The result is frightening.

- Create a domain (dom1.de) on the server
- AkeebaBackup to dom2.de has no access to the data of dom1.de
- Restore a backup to dom1.de
- AkeebaBackup to dom2.de has access to all data of dom1.de

Sorry, but it looks to me as if the sets Akeeba restore the root directory of the domain from 705 to 755. Is that so? Why is this so?

---------------------------

I'm stumped. I have a Manged Server 7000 at Hetzner. Everything is going well with Joomla. Only I can Akeeba Backup Pro with the Joomla Web data see some other domains, backup and load me on my local PC. Hetzner says this and the following I also see a part.

The public_html directory is a system link to /usr/www/users/username
The folder of the user, that user name is in the affected domains set to 755. In other where I have no access, he is set correctly on 705.

Now, on my relatively new Hetznerserver no customer access. I design the pages and have sole access to it. I've just installed Joomla on the sides and done with a few extensions to. I myself was never used SSH on the server. Hetzner said, a script can set this right. On almost all user accounts Joomla is installed, 1.5 or 1.6, ZOO, RSForm, RSSEO, Akeeba Backup Pro RSFirewall. Across each other, not everything, everywhere.

Can really make a Joomla extension or a web server with this crap and put the right of a simple user folders to 755?

With my other hand I get this Pleskserver not access other users.

With Akeeba me down I can click to open /usr/ and can /usr/bin backup'm looking to which user "public" has access and can do everything secure, all data of a completely different customers (domain), without expertise.

Is this really normal?

Maybe someone has one Hetzner Managed server and can test it again? For that he needs but Akeeba Backup Pro. With eXtplorer I'm not there yet, but perhaps there since simpler than going through testing capabilities Akeeba.

Or does anyone know the problem on another server also already had?

Thanks and best regards

P.S. Attached please find a screenshot as I rummage through the files of Domain1 Domain2 mvimmh and selections from the user

Monday, 11 July 2011 07:58 CDT

nicholas

I don't understand very clearly what the problem is. I think you are talking about two issues.

Regarding the two sites which got mixed up, please redo the restoration. When you get to the database restoration, make sure you delete the database information you see and replace them with the new site's database information.

Regarding the permissions, I can't help much. Permissions all by themselves tell me absolutely nothing. It's the combination of user, group and permissions that make sense. For an introduction to those concepts, please read our security chapter.

Under normal conditions, 0755 or 0705 permissions on a directory make no difference whatsoever. That is, as long as the owner user AND group of the directory is private (belonging to your account) there is no practical difference between 0705 and 0755. At any rate, you change permissions using SSH. For example, in order to change permissions of directories to 0705 and permissions of files to 0444, use these commands through SSH:

cd /path/to/your/home/directory
find name_of_web_root_directory -type d -exec chmod 0705 {} \;
find name_of_web_root_directory -type f -exec chmod 0705 {} \;

Where /path/to/your/home/directory is the path to your home directory, one level above the web root and name_of_web_root_directory is the name of the web root directory, usually htdocs, httpdocs, www or something similar.

Does that help?

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!

Monday, 11 July 2011 12:05 CDT

akeebafan

nicholas, you probably meant:

find name_of_web_root_directory -type f -exec chmod 0604 {} \;

instead of

find name_of_web_root_directory -type f -exec chmod 0705 {} \;

right?

Monday, 11 July 2011 12:06 CDT

nicholas

Yes, that's what I meant. I typed the reply too quickly, I guess :)

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!

Monday, 11 July 2011 12:51 CDT

user39436

Hello. Sorry for my English. I have to translate it with Google translator. The difference between 705-755 is very high. If the root folder of the Web is to 705, other users on the server do not have access to my data. I set the folder to 755 all other users of the server have full access to my data. You may like to try this one on Hetzner server.

- Install backup per Akeeba on domain1
- Public_html on domain2 set of 755
- Akeeba from domain1 to domain2 from all folders secure and store it locally
- Set on domain2 public_html back to the default value 705
- Akeeba from domain1 sees only the folder of the user (eg max123). Akeeba can not guarantee to list the folder contents or

I think that there is a strong safety issue. I've restored to an empty domain with Akeeba Pro is a backup. Immediately afterwards, was the public_html folder to 755 Thus, all other users access to my data from the server.

Why does Pro Akeeba the public_html folder to 755?

I must assume that customers with a backup restored. These customers do not even know what's FTP and CHMOD.

I would like not to assign a debt. I find it only matters who can change the problem.

I have created a slide show.

Your text to link here...

Monday, 11 July 2011 12:59 CDT

nicholas

Sorry, the translated text doesn't make any sense. I can't understand what the problem really is, so I will try to help with what I think the problem is.

As I said, permissions alone mean nothing. It's the combination of user, group and permissions that make the difference. Akeeba Backup itself does not change the permissions of the web root.

However, if you use Kickstart in FTP mode then it needs a writable temporary directory. By default, that's created in the same directory as kickstart.php, which is the public_html directory. In order to do that, it might need to change the permissions and this exactly why we strongly recommend NOT USING the default!.

Besides, even if the public_html folder has 0755 permissions it should not be visible by other users on a properly configured server. The fact that you can see it means that the permissions on your server are wrong. What you need is each account's top-level directory (the parent directory to public_html) to have 0700 permissions. This will prevent other users from peeking inside its subdirectories, no matter what the permissions of those directories are.

I guess it's all about sane permissions and how you use the software.

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!

Monday, 11 July 2011 13:12 CDT

user39436

Hello. Have you seen my video? Akeeba changes the public_html folder from 705 to 755. Hetzner in Germany is the best provider in the hosting category. Nevertheless, the managed server must be configured strangely. The support of Hetzner says: 705 is really no other user can see if the data is intended. 755 means that other users see the data. I myself am a web designer. I'm not a Linux expert. I can only write my experiences. Maybe you can investigate the case. On my server changes Akeeba the public_html folder. I think it may be a problem for end users.

Monday, 11 July 2011 13:26 CDT

nicholas

No, Akeeba Backup does not change the permissions of the public_html directory. Please correct the text in your slideshow. Akeeba Backup is the backup component which DOES NOT change the permissions of your web root.

As I already explain it is Kickstart that does it. Kickstart is an optional utility. You can always extract the backup archive locally (e.g. use Akeeba eXtract Wizard) and upload everything by FTP.

Moreover, you are using an old version of Kickstart. Have you tried the new version? Do you see the same thing happening with Kickstart 3.3?

Finally, regarding permissions. 0705 means:
7 -> User has read, write and listing access
0 -> Group has no access
5 -> Everyone else (everyone!) has read and listing access
So, based on your host's description on what works and what not on their servers, they are using a rather unsafe system. All their user accounts are owned by the same group and account directories have too wide permissions (not the suggested 0700).

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!

Monday, 11 July 2011 14:17 CDT

user39436

Hello. Responsible for the change is KickStart. You are right. I downloaded kickstart3.2 45 days ago. I did not know that there is a new version. I will now refer to version 3.3. I have restored data was current as kickstart3.2. To access the other files I get with Akeeba backup. I've used the function of external directories. I first noticed it. I have listed all the folders. So it's a bug in kickstart3.2? Also, Plesk users have all the same group. Plesk has the rootfolder httpdocs 750th I am looking to find the cause. I stick to facts. I love Akeeba Backup and KickStart. It is very simple. I do not want it badly. Please understand me correctly. The change has made kickstart3.2 brought me much trouble. The access is possible at Hetzner is not good. Here, two things came together. If the error is corrected at kickstart3.3?

Monday, 11 July 2011 14:46 CDT

user39436

Hello. Kickstart3.3 behaves. Here again, the folder is changed from 705 in 755.

best regards

Monday, 11 July 2011 15:45 CDT

nicholas

The permissions change was put in place to work around servers based on Plesk 9 which would create files and folders with 0600 permissions, making them unusable. I will create a workaround which does not change the permissions of the site root (public_html) but, still, the directories of your site will be given 0755 permissions and the files will be given 0644 permissions. If you would like to change the permissions after the restoration, please use Admin Tools, go to Custom Permissions, select the permissions you want, save, then go back and click "Fix Permissions".

I can not modify Kickstart to not change the permissions of the directories and files. Unfortunately, I have to provide a generic tool which can cope with all screwed up servers out there and the only way to do that is applying the aforementioned permissions.

I still maintain that the need for 0705 permissions is just plain wrong. It signifies an incorrect server setup (according to the information that you have given me). If you want a really safe server setup you should be using suPHP on your server, so that each account's site runs under a different UNIX user, in which case it suffices to give the home directory 0700 permissions. This is the only way to provide complete isolation among sites. Everything else is just a futile effort, IMHO.

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!

Monday, 11 July 2011 16:26 CDT

akeebafan

It depends on how Hetzner organized their users and groups.

If you have ALL "customer users" in one `group`, then 705 could work. All users of that `group` (except the `owner`) wouldn't be able to read any file in that `group`, because the `group` permission is 0 - even if `other` is to 5.

In that setup all "non-customer users" would be able to read/execute files of all customer users. My guess now is that only Hetzner runs processes that belong to `other` and not to that `group`, to make this setup secure.

Monday, 11 July 2011 17:03 CDT

user39436

Hello. I understand that
I now know that the server settings are weird by Hetzner. I hope you understand, it was to have access to the other data a shock for me. I hope that Hetzner programmed a setting where the change of law is prohibited from public_html. I myself can quickly set the FTP folder on 705. As long as the configuration changes Hetzner not, I will restore itself to perform for my clients. I'm going to look at the Admin Tools. Best regards

Tuesday, 12 July 2011 02:08 CDT

user39436

Hello. In search of a solution, I now write to me with many users in Hetzner forum. A user has viewed the kickstart.php. "A grep on the kickstart.php me alone provides 15 possible places where he wants to put 755 ..."

Would it be technically possible that kickstart works safer?
- Folder read rights
- Change folder permissions
- Data restored
- Folder permissions to write again to return to the original

Best regards

Tuesday, 12 July 2011 02:38 CDT

nicholas

Please read my posts above. I am not going to reply anything else on this thread.

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!

Tuesday, 12 July 2011 08:37 CDT

user39436

Hello. You need to no longer respond. I read the article. I do not want change you kick start so that it does not change any files and folders. The reality is this. Kickstart changes the rootfolder from user. It's all about the rootfolder from the Web. This is not included in the archive. Kickstart changes the rights of a folder on a server, this folder is not part of the archives. Kickstart should not set the folder to 755. No matter how the server is configured. If there is no other technically feasible, the user must get a message. I can not understand why you can not understand. Too bad. Akeeba Backup and kickstart are very good programs. I paid for that time like 40 EUR for Backup Pro.

Best regards

Tuesday, 12 July 2011 08:41 CDT

nicholas

Changing the permissions of the root directory is, as I said, a bug which I am going to fix. I've written the fix, I just need to test it before I publish a new dev release that you can test. I thought you were talking about the other directories of the site except the web root. These are the directories whose permissions I need to change.

I apologise for my last post. Something was lost in the translation and I understood something completely different than what you said :(

Please give me a few minutes to publish a new dev release of Kickstart which fixes the bug.

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!

Tuesday, 12 July 2011 08:47 CDT

user39436

Hello. Take your time and test alone. I go on holiday for a week. I'm relax, that it was a misunderstanding.

Tuesday, 12 July 2011 08:52 CDT

nicholas

Good! I didn't want to appear like we are disagreeing when we both agree on the same thing :D I just uploaded the (partially tested) dev build. It's on https://www.akeebabackup.com/download/developer-releases/kickstart.html

Please download and test at your convenience.

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!

Tuesday, 12 July 2011 09:18 CDT

user39436

Hello. I'm sorry. The public_html folder is still changed from 705 to 755. This happens solely through the unpacking with KickStart. Do I have to go through the installation routine completely?

Tuesday, 12 July 2011 09:24 CDT

nicholas

No, it means that the fix didn't work. I'll take a fresh look at it later today. Look for an updated dev release tomorrow!

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!

Tuesday, 12 July 2011 10:17 CDT

user39436

Hello. Tomorrow I'm in Spain. :-) I will test it next week. many thanks

Tuesday, 12 July 2011 12:36 CDT

nicholas

Hi Martin!

I got it nailed now :) Please find the properly working dev release svn785 at the usual place.

Thank you for your 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!

Monday, 01 August 2011 04:06 CDT

user39436

Hello. By svn785 it works. The public_html is on 705.

best regards

Monday, 01 August 2011 04:07 CDT

nicholas

Awesome! I'll release a new Kickstart version once I get back from Joomla! Day Chicago :)

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!

Monday, 01 August 2011 04:08 CDT

user39436

Ohhh. Have fun in Chicago. best regards

Monday, 01 August 2011 04:09 CDT

nicholas

Thank you :)

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