I generally agree that we should try and come up with ways that are safer than just opening code trees up for modifications, and that some safer process (perhaps a handshake with a cron job that could run as a different user and pull plugins) would be a better approach. It's always bothered me a little that cron.php is an exposed unauthenticated admin process. But I also agree with the concept that jQuery plugins aren't the same as PHP code., cause they don't execute server side. Whether we like it or not, there is some precedent for writing "core files" into the system files path and letting clients download it from there. Not that I'm advocating this approach mind you, but the Theme Developer module writes tpl files and css files into the "files" path and then lets people execute code server side from that path, and even drupal core rewrites css files and image files into the systems files path. You could perhaps argue that these aren't code, but I just was sort of pointing out that that it does meet the definition of core files, even though it ain't code. Food for thought: Would we eliminate support for flash uploads because flash gets used for client side coding as well? Hmm... I also wanted to point that out so that we don't al get a false sense of security regarding code that uploads files. If I can get a module to upload code (through a bug) into the files path, then I can still leverage that code in really nasty ways. In other words just cause we're not uploading files to the modules directory doesn't mean we've protected ourselves from php file upload vulnerabilities. All code that contains the ability to update files on a server needs close scrutiny. Just trying to share a different perspective (I can argue both sides of any issue :) and do more often than not). On Sep 13, 2007, at 6:11 PM, Derek Wright wrote:
On Sep 13, 2007, at 5:34 PM, Earnie Boyd wrote:
How can this become an issue if only administrators have the privilege?
Various other people in this thread were proposing that the site could automatically download and install/activate jQuery plugins (either new plugins, or new releases of existing plugins). This would require the website having write access to its own jquery plugin folder. This is the giant security hole we've pointed out, and which you seem to understand.
The confusion is between people who sanely understand that the only safe solution to this problem is for the human admin to manually upload/install new jquery plugins outside of drupal (scp, ftp, rsync, whatever -- some process with write access to the drupal sources which is *NOT* initiated via httpd and php) and the people who think that the site could somehow upgrade itself.
To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser). That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.
Hope that helps clarify, -Derek (dww)
p.s. If only shared hosting companies understood this. :( Sadly, most of them seem to run all of your httpd and php processes as the same user that owns all the files (presumably since that's easier and cheaper for them to manage, do accounting on, suspend your account when it uses "too many resources" etc). But, what's more profitable for the shared hosting provider is more dangerous for the customer. Ahh, the joys of capitalism.