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

[Sammy Spets]

Again i'll emphasize that it was an example and NOT a suggestion. You're 
jumping all over it like it's on fire. A little hot under the collar?

I'm going to bow out of this discussion while I still have a head on my 
shoulders. I'm obviously out of my league.

-- 
Sammy Spets
Synerger Pty Ltd
http://synerger.com

On 21-Nov-06 19:23, Derek Wright wrote:
> 
> 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  
> upgrades"...
> 
> -derek
> 
> 
> 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? ;)
>