I have been working with the Drupal CMS extensively since the beginning of this year. Having worked with DotNetNuke earlier, I was initially sceptical about Drupal’s capabilities. But after having a good look at Drupal, I must say it is good.
Now, coming to the point, I have had one big problem with Drupal right from the start, the Drupal_Security_Do_Not_Remove_See_SA_2006_006 SetHandler directive in Drupal’s files’ folder, which looks something like:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
If you have never heard about this problem, or want to know more about it, information is available here and here.
In a nut-shell, a bug in Drupal core allowed malicious users to execute arbitrary code on your Drupal website by uploading .php/.php.txt files to the server. In response to this, the solution that Drupal came out was to add a SetHandler directive to the .htaccess file of your sites’ files folder, and set an invalid non-existent Handler for all files in that folder. This effectively meant that Apache returned an error trying to parse any file in this folder, because this directive forces matching files to be parsed through the handler which does not exist. So, this ultimately prevents execution of any code through the sites files’ folder.
According to this issue for Drupal core (check this & this comment), the bug in the Drupal code has been resolved. However, the advisory is to still keep this directive in .htaccess file, because some seemlingly innocent files (like .php.txt) get executed as PHP in many configurations.
Now, this directive has caused me a lot of heart-burn & head-butting right from the scratch. Due to the above mentioned non-existent handler issue, the sites’ files folder practically becomes inaccessible to anyone except the owner (unless you have chmod’d it to 777 which itself would fail unless you do it from Drupal itself or from the user account which Drupal runs under).
However, your Hosting CPanel & your server usually run under different user accounts. On dedicated Hosting, you can easily perform this action under the web server’s account. But, in almost all of Shared Hosting plans,you cannot impersonate any user account, and your access to Hosting space is available either through your Hosting Panel, FTP, or your site. As Drupal creates this folder, this situation leaves this folder inaccessible via Hosting Panel or FTP. You cannot perform any actions (like creating/modifying/deleting files or folders or changing their permissions) to ay folder beneath this folder.
Even if you somehow change the permissions to 777, you make this folder publicly available for modification which again poses a security risk.
My frantic search for a Drupal file manager module allowing me to play with this folder proved futile. None accessed the original folder but only sub-folders beneath it. Ultimately, I decided to do a module myself, that allowed me to play with this folder from within Drupal.
The module is available at:
http://drupal.org/project/take_control
This module allows an admin to take control over the “files” folder back by setting permissions to 0777 on it.
This module even allows authorized users with access to it to delete files (optionally recursively) on the system, or just change their permissions. This way, they get back control over their installations.
After changing the permissions, you can perform desired tasks, and then again restore the permissions, as nothing happened, and Drupal is happy too (with the file folder protected).
I believe this module can be useful to the community, as I see many people in my place who might need it. I intend to extend it further by more features where admins can specify permissions to apply on all files in a directory matching a pattern to a particular value in one go.
Currently, this module allows you to take control of the file-system folder by specifying custom permissions on it from Drupal. Additionally, you can specify delete any directory/file owned by Drupal using this module.
However, remember to restore the permissions (especially for the file-system folder) to maximum 755 after you have performed your desired tasks to prevent any security issues.
I have plans for allowing renaming/copying of files/folders in the next release of this module. Additionally, I plan to provide a full-fledged File Manager for Drupal (like that available in CPanel) in the next-to-next release of this module, (which might take some time as this is a challenging task). However, the immediately next release for this module (allowing renaming/copying) should be available in the next month.
UPDATE: (Feb 20, 2010) – The permanent address for discussion of the Take Control module on this site is:
http://www.rahulsingla.com/projects/drupal-take-control-module
This is wonderful, thank you for your work. I was just looking for solution like this.
How the path to the file have to looks like? Thanks!
The interface of the module clearly mentions that it needs to be an absolute file-system path. e.g.
/home/domain/public_html/domain.com/sites/default/files/images
or
/home/domain/public_html/domain.com/sites/default/files
Also, notice NOT to give a trailing slash at the end of the path. This could either be a directory or a file-path. If this is a directory, permissions can be applied recursively by checking the “Recurse directory” option.
The next version of this module would support both absolute as well as relative paths (relative to your Drupal installation directory).
HI Mr rahul,
Im beginning in druapal, i already install the module, but whould like to change the default path in the code. I hava had to do it.
Im changing the file filesystem.inc in the line 12,
return (dirname($_SERVER[‘SCRIPT_FILENAME’]));
I enter my path of the form c://folder/ changing the option $_SERVER[‘SCRIPT_FILENAME
but I had gotten good result.
Can you help me please??
Hi aldo, I assume you want to change the path where documents are uploaded. You need not change it in code, you have an option in Administration area that allows you to do just the same (Admin > Configuration > Document). The documents would however alway be uploaded in a sub-directory of Drupal’s file system folder.
You should not try to move it outside this folder, because Drupal/web-server might not have access privileges to that folder, and moreover if you move it outside of your web-server root, the document would get inaccessible over web if Drupal uses public file-system, and might be inaccessible for private file-system too depending upon your environment.
Oops, just noticed this comment is for Take Control module (not the Document module). Why would you want to change any path here for the Take Control module. In fact, there isn’t any path that is configurable and you would like to change (except for Exts directory that needs to be under sites/all/libraries).
Good answers in return of this query with firm arguments and describing all about that.