Posted by matteoraggi on April 21, 2009 at 10:37pm
Jump to:
| Project: | Backup and Migrate |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | mchrisneglia |
| Status: | closed (fixed) |
Issue Summary
on www.forniture-alberghiere.net and all other sites is all ight instead on www.rnhotels.com now only I wasn't able to access to admin, but also I can't download files from file manager and ftp, i walways receive accesse denied, but I see the files stored and I can'd download and copy them and also changing permission to 777 I can't download backup fiile,s how I could do it?
Comments
#1
Essentially, you have to be root or have sudo'er ability to be able to access those files through the file system. The web server user (apache or 'nobody') is creating the temp files with 600 permissions in the code itself and then not adding any other more elevated permissions on the files for the group or 'other'. What this means is that you won't be able to apply any permission changes through FTP and that's why you're having the problems you're having. I'm having the same ones.
The backup_migrate.module uses the function tempnam() on or around line 918 ish creating 600 permissions.
what this means is that you have to use the interface in order to download the files out or come up with a more clever scheme for handling your files outside of drupal itself.
I am reluctant to suggest hacking the module, with a chmod() called in code after creation of the temp file as a 'quick fix' because of any other security implications it may cause but it *is* an option. It's probably better to have too-strict security than not enough and since this module is dealing with your database, it's more important to have more security than less, imo. This was likely done on purpose to protect those files but I admit for the time being there's not a good configuration option around it to my limited knowledge.
what i've done for the time being is add 0640 perms on the created file in code using the chmod() function and ensured that the ftp users are in the same group as the webserver, so that they have read permission, but no one else does. Clearly this is not the best solution but it works until we have a script that will place these files outside of the webroot into a more protected folder.
best, Chris
#2
Chris's summary pretty much nailed this. The module locks down the files as much as it can since they contain sensitive data.
If you update to version 2.x there is a built in option to change the file permissions of backups after they've been saved so that should avoid the need to hack the module.
#3
Automatically closed -- issue fixed for 2 weeks with no activity.