Closed a security hole
The blogs reside on the public area, and when scanning the report on unwanted accessed as derived from the webserver logs, I notices that some way, the full path has been exposed. This means any user has access to the configuration file – that contains database access information. The file needs to be accessable by the web-user (HTTP$NOBODY) – READ at least – to allow database access. There is no esy way to get around it, and certainly not in a short period.
So the only solution was to get the database access data out of that file and store it in a safe place, that cannot be accessed using the webserver directly. It’s a minor change in the PHP code: just include a file containing the sensitive data.
This has been done now -a dn the access data has changed.
This is a change to be proposed to the wordpress team.
MySQL slower – but more stable
At least, I didn’t notice any MySQL breakdown in the past weeks. It’s quite a bit slower – all buffers half as big as before – but considereing the problems encountered, the current preference is stablity above speed.
The batchjob that keeps an eye on MySQL runs every 15 minutes but hasn’t find a MySQL-Server process missing, so far.