chasd wrote:
I suppose the folder could be moved to/from a folder that is not
web-accessibleI think that is the best approach if you are concerned about security.
I would still prefer it didn't exist at all on an existing install, as it shouldn't be necessary. :)
You could have an apache directive forbidding access to "installer1"
Or even for 'installer' for that matter, and the warning message could check for such a condition.
but that would only further complicate the situation.
If you have an automated way to do it, the complexity is hidden and
forgotten.
I'd prefer a simple/elegant solution over hidden complexity. In my experience, that would inevitably lead to breakage down the road and more confusion over how to fix it (unless it's well-documented).
Here is another interesting possibility: Could the installer chmod
itself 000 after it is finished running?The possibility I thought of was to tar the directory up before
removing it. When it comes time to update, untar the file.If the files are tarred up, they can't be executed, only downloaded.
That's another good possibility. Given any of these choices, though, I would go for the simpler choice of aliasing "svn up; rm -rf installer/".
Here's another choice: Have a config option, that if absent (either left out or if there is no config file) activates the installer. It could be something like $rcmail_config['post_install'] = true. If the variable is set, the installer scripts would die or become inactive.
Some other projects use such a variable to prove that you have edited the default config.
Jim _______________________________________________ List info: http://lists.roundcube.net/dev/