Although I see your statement that you don't believe it is insecure for the webserver to have access to rewrite its own php code - there is opinion within Drupal security moderators that this is to be avoided.
Although I believe this sort of functionality has its place sometimes, it should only be done by someone who understands the implications and risks, and has the ability to recover from catastrophic failure. This does not always apply to random Drupal users who just install a contrib module assuming that because it's public they are 'safe'.

Bearing all this in mind I'd suggest a strongly worded note on the project page explaining the possible risk of allowing website visitors to potentially execute arbitrary PHP code on your server if this module is installed. I think the security team would agree! Cover your bases and let the downloader beware.

Don't get me wrong, I think this module idea is great, and has its place - but it's place is on a private dev site - not public shared hosting :-)

Comments

Copyfight’s picture

Copyfight commented

Wordpress allows to change theme files on the fly, too.
Does anybody know how do its devs faced the security issues?

Moreover, in WP you can also upgrade the core files via the web interface: are they crazy? I suppose not. ^^

shane birley’s picture

shane birley commented
Status: Active » Closed (duplicate)

I agree. WordPress is a great tool but it its primary focus is a multi-user(s)/single website framework. The WordPress themes being edited are the themes for each individual blog. WordPress does not have a default multi-site consideration because it doesn't have that functionality - they have an entirely different product for that. (You will note WordPress MU does not allow access to the main themes directories from each individual blog either.)

Drupal is a multi-site, multi-user environment and allowing access to core Drupal directories via any module is nuts. If you are the only user on the system and have only a single website, then it may be conceivable to allow such access. But with so many Drupal installations running several websites (that potentially have very different audiences), allowing this kind of access is never a good idea. I don't want to imply this is a security issue surrounding Drupal, it is not. It is a security issue around this module. Great idea, not-so-great implementation.

Also, a note about the "...WP you can also upgrade the core files via the web interface..." - if you're familiar with WordPress enough, you will note that you permit WordPress access via a separate FTP account and not "technically" done via the web interface. It uses FTP to do the work and then executes the changes that way using a non-Apache user to move and copy the files.

This issue is related to another ticket. I will set this one as duplicate. See my little rant here.