Option to set frequency for testing access to backup_migrate/scheduled/test.txt

Yes, this is backup and migrate checking those directories to make sure they're secure. Access should be denied in this case (that means your db dumps are not publicly accessible). I need to work on a way to reduce the frequency of these checks so that the module produces less log noise, but I want to make sure I'm checking often enough that server configuration changes aren't leaving people vulnerable.

thanks for this info! kind of panicked with all of those "errors"!

Glad to find this answer... but maybe these checks could be a user-configurable option, or you could rename that file to ignore_this_error.txt or put some text explaining that this error is normal inside of it?

The logic would be to check it when visiting the status report page...

Background - for newcomers:
This log message is to confirm that the folder that contains the scheduled backups is inaccessible from the web, as we "normally" do not want anyone to access the backup files, hence have to ensure that folder is protected and available only for Drupal itself (or through server logins with SSH/FTP/etc., but not for anonymous browser users.)

The current log entry now on D7.x (path example may vary) is:
Type: "access denied"
Location: "[path]/backup_migrate/scheduled/test.txt"
Severity: "warning"

And it occurs in the log as often as the backup runs.

IMO this should be configurable, as it is cluttering the logs far too much.

The current behaviour is often ok on new sites, but later after the security of a site is "set" and there are no reasons to suspect these folder permissions to change outside our control, then it is not ok to clutter the logs with this same entry so frequently anymore.

Suggestion:
1) A setting which would let us specify the frequency of that check to a select list of - say - Daily / Weekly / Monthly, or the like would be nice.
2) As @Dane suggests in #4: give that txt file a useful name like "this_test_file_SHOULD_NOT_be_accessible.txt"
3) And @jvieille's idea from #5 in addition: report the status of that file access whenever we visit the status report page, and show its status there (with fresh data from "0 seconds ago", not the latest log entry.., and then log THAT check to the db along with the others).

Reopening this issue as it seems to be _the_ reference for people searching for this before they know it is by design.
Then we have all this info in one place. (Thus changing it into a feature request.)

mmm... regarding the name of the txt file in 3)..., plus some thoughts about its permissions and the related documentation (README.txt file) (about the actual test in question here):

(I choose to go into details here also as a courtesy to newcomers finding this issue online. But the hope is mainly to let some of this find its way into the README.txt file as well. Or if for some reason it does not, then at least a link to this issue could be added there, for example.)

- the txt file name (currently just named "test.txt" in v. 7.x-2.4) should reflect that the file access check is done to indicate that the access protection is adequate to prevent browsers access to the content of the backup folders. That test file is placed there by Backup_migrate during initial configuration, and that test.txt file itself has "604" permissions (at least that seems to be "out of the box" on my server environments when enabling Backup_Migrate and configuring the folders...).

On my server environments, that test.txt file seems to be assigned 604 permissions automatically, and the backup process seems to automatically assign 644 permissions to each new backup file subsequently, but that is perhaps merely a logical mismatch, not quite a practical problem(?). (The difference between that 0 and 4 is no access for "default group" vs. read access for "default group". On many drupal server environments, the "default group" is not used or should not be used, so this may be irrelevant.

I would say that it should be a configurable option within Backup_migrate to decide on whether or not to give "default group" those read-only permissions, but that is for a separate change request.

From the current version 7.x-2.4 README.txt file:

"VERY IMPORTANT SECURITY NOTE:
Backup files may contain sensitive data and by default, are saved to your web
server in a directory normally accessible by the public. This could lead to a
very serious security vulnerability. Backup and Migrate attempts to protect
backup files using a .htaccess file, but this is not guaranteed to work on all
environments (and is guaranteed to fail on web servers that are not apache). You
should test to see if your backup files are publicly accessible, and if in doubt
do not save backups to the server, or use the destinations feature to save to a
folder outside of your webroot."

(That is all, currently no more info about these file permissions in the README.txt.)

So... - logically that means that...;
- as long as the htaccess rules are actually protecting each used folder, then the file permissions "could be irrelevant"(unnesessary), depending on the combination of the actual file permissions and the server environment...

That is not sufficient documentation, IMO.

That docs section should be updated with some of the above descriptions plus something like the following as a recommendation example for how the file permissions could be set to make sure that IF the htaccess rules for some reasons do not work, then the file permissions will come to the rescue.

The backup folder(s) should for example often have permissions set to "700" or whichever is suitable for the site/server in question as long as it is not accessible for web browsers, so that only the backup process can access and save new files into it, while nobody can access those backup files through a web browser. All new backup files that are saved into it by the automated/scheduled backups (and manual ones when using the server folder option), will all be assigned 644 permissions by the backup_migrate module and thus be automatically properly protected.

The check does NOT attempt to verify the actualy file permissions for Drupal's ability to write to those folders, but just tries to "fetch" that test file to deliberately trigger an "access denied" error, which serves as a confirmation that the file and folders are actually/sufficiently protected from prying eyes.

Some clues to people as of which permissions can be suitable, and what to check for when doing security audits or the like:
- 700, 740, 750 or 770 permissions for each backup (sub-)FOLDER (each one actively used on the Destinations settings page).
- make sure there is a .htaccess file with the above quoted content in each of the backup folders, having 444 permissions. (IIRC, when adding folders to use within Backup_Migrate UI itself (through Drupal), the module will actually create and place a default .htaccess file in each new folder with 444 permissions. (including this as a check point here may be helpful for people in need of a check list to manually verify that they actually have one each, with those permissions and that exact content.)
- for any other potentially existing files (older backups, etc.) in those folders: make sure they have 644 settings (?), using ssh (and the command "chmod 644 *") or through FTP/FileZilla or an online File Manager.

(The below htaccess file info is already in place and given 444 permissions AFAICS, I am just adding this info here as a suggestion to what should be added to the README.txt file)

The .htaccess file(s) in each of the backup folders should have 444 permissions and contain (only...) the following lines:
**************
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks
************

Finally, regarding the file name of the test file:
Perhaps a better txt file name would be:
"backup_test_file_permissions_(access_denied_from_browsers).txt" ..?

The 3.x branch performs this test only once and marks the directory as safe. This should reduce the number of logged errors significantly

Could this be backported to the stable version until 3.x takes over?

Not fixed, this MUST be backported to 7.x-2.x-dev!

Respectfully disagree. If you really need the feature then upgrade to the 3.x branch.