SyncDB icon indicating copy to clipboard operation
SyncDB copied to clipboard

Move syncdb script and config up a directory

Open markchitty opened this issue 11 years ago • 4 comments

My WordPress website is running on a shared server which is running nginx instead of Apache. This is cool, modern and fast but has the major downside of a) no .htaccess files to configure handy server settings and b) no access to nginx.conf to configure handy server settings (this is fair enough on a shared server).

The upshot of this is that the syncdb scripts and /.bak folder containing the DB backups end up sitting in my /public_html folder for all the world to see, download and use in their nefarious hacking attempts against my site :(.

I am in the process of writing some cleanup move/copy commands on the end of the syncdb script to sort out this problem. However, I've always thought that the syncdb scripts don't really belong in the web root folder anyway as they're not intended to be served as web site resources.

Can the script be redesigned to run from the folder above web root? DB backups should be saved into a folder in this location (above web root) rather than within web root. How does that sound?

markchitty avatar Aug 01 '14 17:08 markchitty

Totally agree. Also, I use Git to deploy my codebase to the remote server and I'd like to simply keep syncdb script in the repo, but not in the webroot, without any 'cleanup' actions.

tevashov avatar Aug 25 '14 11:08 tevashov

Ditto: I'm using git to deploy too and I'm .gitignore-ing syndb* when I'd rather it was included in the repo.

markchitty avatar Aug 25 '14 12:08 markchitty

Yes, but it's handy to keep syncdb with it's config as actual part of the repo and not as just ignored files in working copy directory.

tevashov avatar Aug 25 '14 12:08 tevashov

This is a serious problem, no? Since WordPress is already a popular target of hackers, they could easily add a routine to check for the existence of /syncdb-config. If found, download /.bak/latest-remote.mssql.bz2, for instance, and download the database which includes wp_users with passwords. Everything else seems to work fine, but this security problem makes it unusable. Is there a solution to this?

dyske avatar Oct 05 '16 19:10 dyske