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? ;)