WordPress needs all of the wp_ tables. It doesn’t have the ability (that I’m aware of) to differentiate DB calls based on user permission levels.
Inside WP itself, if a user doesn’t have permissions to something, it cant’t do it (like if you can’t add users, you can’t add users), but since WP relies on the info in wp-config.php, and it needs full read/write access to the DB to add plugins etc, you’re just going to have to have that as is.
I’m aware of that…but, if only the front-end is displayed, then only read access (for example) should be needed for wp_posts…the front-end should never need write access to a post.
From what I can tell, the only thing that the front-end would write to is wp_comments and wp_commentmeta (as well as read access to all the other tables), but I don’t know enough about WP internals to know if there is something else that the public facing side of WordPress needs write access to.
I’m not sure if I was clear enough about my setup, so let me try and clarify a bit. I have two separate WordPress installs, but both connect to the same MySQL database, but with different DB users. Some notes on each install:
Install One:
– Accessible to public Internet.
– Has HTTP access to the /wp-admin folder and /wp-login.php file denied in the Apache config (as well as quite a few other security pieces in place, but none of those are relevant to this problem)
– Cannot (and should not) be used to preform ANY administrative tasks (administrating users, adding/removing posts, moderating comments, etc.)
Install Two:
– Accessible only from my internal network
– /wp-admin and /wp-login.php are fully accessible
– Separate install, but connects to the same DB as “Install One”
– All administrative tasks should be done though this install
I hope that clarifies things a bit. The whole issue I have is that I don’t WANT “Install One” to be able to add users, plugins, etc. All that should be done from “Install Two.”
So, I assume “Install One” should be able to run with read-only access to most DB tables. “Install Two” will be left with full (GRANT ALL) privileges to all DB tables.
I’m trying to wrap my head around how you manged to get two installs in not only the same DB, but with the same prefix, so basically you have two accounts using the same exact DB… That…
Okay. I suspect you CAN do this, but I think you’re going about this the wrong way. Keep in mind: If no one’s going to be logging in via the external internet (not your intRAnet) then you just need to give access to wp_comments so people can leave comments. But that would void your desire to not have POSSIBLE ability to approve comments.
If you’re not having comments, then you just need read-only. (I would also turn off pings, god knows what would happen if those were ON and the db locked)
I am currently setting up a WordPress installation for a client with higher security needs that an average install. I currently have things configured so that the WordPress admin can only be access from inside our network.
You can do that without all this extra work by using .htaccess to trap the visitor’s IP (if not from inside your internal network, don’t let ’em in)
http://www.mattcutts.com/blog/three-tips-to-protect-your-wordpress-installation/
Thanks, that is the information I was looking for.
Just a side note: The reason that I am using two separate installs is so that I can restrict DB access to the public one, stopping any possible SQL injection attacks (well, that, plus mod_security, but layers of security can never be a bad thing :).)…as well as cutting down on any damage that could be done via code execution hacks by using a combination of Apache’s mpm_itk and POSIX ACL’s (allowing each install to be run under a different Linux user, with different rights.)
