[development] RFC: letting modules phone home to check for new releases
sammys-drupal at synerger.com
Wed Nov 22 04:10:42 UTC 2006
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.
Synerger Pty Ltd
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
> >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