[development] RFC: letting modules phone home to check for new releases

Derek Wright drupal at dwwright.net
Wed Nov 22 03:23:27 UTC 2006

On Nov 21, 2006, at 6:46 PM, Sammy Spets wrote:

> My example is a way to ensure the
> update procedure is legitimately run by the admin user and thus can  
> use
> the webserver process uid to replace files (which is necessary for the
> files to be usable by Drupal).

no offense, but this is exactly the kind of sloppy approach to file  
system permissions that leads to sites getting hacked and drupal  
getting a bad name. :(

your Drupal source files *DO NOT* have to be writable by the  
webserver process uid for "the files to be usable by Drupal" (!!!).   
the "files" directory is a special case, which is why a) it's been a  
source of numerous security issues and b) it should be handled with  
intensely defensive programming by anything that's touching it.

that aside, your Drupal source files must be _readable_ by the  
webserver process uid, period.

your Drupal source files *SHOULD* be _writable_ only by a *DIFFERENT*  
process uid, namely, your "high-privilege admin" user (could be root,  
but doesn't have to be, so long as it's *NOT* the same as your httpd).

until people completely understand this, they'll a) continue to fill  
up this thread with confusing posts that don't advance the end goal,  
and b) continue to setup insecure websites.

"automatic" upgrades, in whatever form, imply that some automatic  
service is going to be overwriting things in modules/* under your doc  
root.  that requires that the automatic service has write access, and  
that means trouble.

unless the human (with the different uid, and higher powers to do  
damage) runs a script to trigger the upgrade (after backups, etc),  
life sucks.

so, if we're all clear on that, and we want to discuss exactly how  
much can be automated into this script, what the UI looks like, etc,  
etc, that's all fine and good, but a) it's premature (i'm just asking  
about agreement on what goes in the .info files to make all this  
possible) and b) it's a different discussion than "automatic site  


p.s. sure, friendly amendment about downloading to a tmp directory  
and only putting the site in maintenance mode for as little time as  
possible is totally reasonable.  i wasn't being as careful about the  
exact steps in that reply, since my main point was *THE HUMANS MUST  
DO IT* or life sucks.

p.p.s. did i mention that human intervention is required for this to  
be a good idea? ;)

More information about the development mailing list