claudel

It is *not* an issue of people being able to read the credentials file via a browser.
Part of the problem is that the webserver (apache) runs as an unprivileged user, which is good. The bad part is that the credentials file needs to be readable by the webserver, which means the file permission needs to be world read, which allows other users on the shell machine read access as well as the webserver. I’m almost to the point where I can spend enough time to work out a solution, and I’ll post here what I figure out.

Claude

I have a personal account with the same ISP that is different than the one that hosts the website, so I can easily check…

thanks

Claude

I’m running a new test installation with only these privileges enabled for the USER_NAME that opens the database:

Select_priv
Insert_priv
Update_priv
Delete_priv
Create_priv
Index_priv
Alter_priv
Drop_priv

and it seems to work.

Some of these might be unnecessary, but I don’t believe so.

Claude

Assigning ownership to the webserver is not a bad idea.

I’m also going to try and install it in a wrapper as Sonic suggests. Supposedly that will protect against snagging it via a script.

It amazes me that nobody has come up with an effective remediation strategy for this vulnerability.

In my case, I am not dealing with any data that is particularly valuable or sensitive. If I was, I’d be quite disturbed at the potential for compromise.

Thanks

Claude

Yeah. I saw that.

It doesn’t address the problem of other users at the same ISP being able to read/copy files from the directory unless they are mode 600…

It also doesn’t say how to start WP *with* the credential file protected.

The web server needs to be able to read it.

Thanks, though.

Claude

Hi

I wound up adding a link with a button to the sidebar.

That’ll do for now.

I’m gonna check out “wp-admin-bar” plugin too for later…

thanks all

Claude