Up to date with #106.
The MTimeProtectedFileStorage protects against "rogue" upload scripts that take filenames from $_GET. Unlike so many threats this is being used in the wild to hack sites and the problem is that often these scripts are standalone , not need Drupal, just sit there forgotten. Now with Drupal 8 including these files; you can't even protect by putting the filedir outside of the docroot cos an attacker could rely on Drupal *including* generated PHP files. So I somewhat expect MTimeProtectedFileStorage being used in a lot of setups, not just shared. At the same time, we want to use the php storage for many things -- joachim suggested dumping the module implements cache into this, I suggested regenerating entity classes on field CRUD and using the container directly. So this will again add to the widespread usage of php storage. We need this to work satisfactory to many, often contradictory requirements. Currently, however when the webserver runs under a different user than the command line user, you can't use drush with these files, it's impossible to read these from an editor/debugger and so on.
We need to relax permissions while still remaining secure. We decided that the non-listability of the directory is not important against rogue upload scripts as you can't list the directory easily (like .htaccess disabling directory listing) and so you need some arbitrary PHP code to obtain the filename. And much good the filename does to you: if you just write it the mtime will be higher than the directory mtime and that's invalid. Deleting and writing a new one changes the directory mtime and so that's invalid too.
Review and commit.
In short: install from GUI, drush cc, check php directory empty; clean up; install with drush; clean cache from UI; check php dir empty. Detailed:
Please post your results, even if you only get part way through testing. :) Thanks!
- You need an environment where the web server user (like www-data or http) is different from the user who runs drush from command line. Most Linux environments are set up this way, most Mac OS and Windows setups are not. If you use MAMP Pro, you can meet this user/environment requirement via the GUI which under the General menu item allows you change your Apache preferences to use 'www/mysql' instead of 'youruser/youruser'. After making this change you'll need to restart Apache, and then you can verify the user/status for the Apache process by running 'ps aux | grep apache'. Additionally, in php.ini you may need need to increase the memory_limit to at least 128M and max_execution_time to 60 setting in MAMP's php.ini file (you can edit this in MAMP Pro via File > Edit Template > PHP > 5.3.20.php.ini)
- You need drush from github master (do a 'git remote -v' in your drush directory to see if it is using github. If it is, '
git pull --rebase'. If it is not coming from github, remove it and clone from github.)
- Patch drush (from github) with https://drupal.org/files/drush-do_not_test.patch this actually removes a currently necessary hack from drush.
curl -O https://drupal.org/files/drush-do_not_test.patch
(or use wget instead of curl -O)
git checkout -b somedrushbranchname
git apply --index drush-do_not_test.patch
git commit -m "cm permissions drush patch to remove hack"
In order to show the drupal patch works, we need to verify the problem exists first (without the patch). Then later redo the steps with the patch.
- Make sure you have the latest drupal from git. '
git pull --rebase' in your drupal docroot.
and clear out previous install:
sudo rm -r sites; git checkout sites; git status; cp sites/default/default.settings.php sites/default/settings.php; mysql -uroot -proot -e "DROP DATABASE drupal";
- Do not patch drupal (so you should see an error in step 7).
- Patch drupal. patch (from #98 or more recent. copy the address into paste buffer and use it in the curl or wget.)
curl -O https://drupal.org/files/1908440_102.patch
git checkout -b cm-perm
git apply --index 1908440_102.patch
git commit -m "cm permissions patch 102"
---- now we can test -----
- Now install from the UI (that uses user www-data or http). Note the core/INSTALL.txt has instructions for setting permissions on sites/default and settings.php. It says to reset permissions when done, but we will be removing sites and getting it back out from git when we are done and then reinstall. Now try
drush cc -y all(that uses your command line user).
(without patch/4.1) Should see error: ...
(with patch/4.2) With the drupal patch (from #98 or more recent) , no errors should occur.
- Then clean up (remove files directory, clean settings.php) try to reinstall with drush si (if it works; there are reports when it doesn't in drush issue queue.) Now try to clear cache from the UI.
(without patch/4.1)) Should see error: ...
(with patch/4.2)) With the drupal patch (from #98 or more recent) , no errors should occur.
- Cache clear should remove the
Note: this means to review, install has been done 4 times. without the patch, in the ui. without the patch, with drush si, with the patch, in the ui. with the patch, with drush si. Between each of these installs, the old site needs to be wiped out and start clean. See the steps in 4, but key is removing the sites default (files, php dirs and the settings.php) and also dropping the db.
PASSED: [[SimpleTest]]: [MySQL] 58,740 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 58,817 pass(es), 1 fail(s), and 0 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: PHP Fatal error encountered during run_tests.sh. See review log for details.. View
PASSED: [[SimpleTest]]: [MySQL] 59,216 pass(es). View