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