Core Integrity Checks After Move

I have the same issue. It has something to do with certain files (or the whole directory) not being set to 777 in wp-content/uploads/sucuri — which is generally good security policy. And here I thought this was a security plugin. ??

@mopquill I take security seriously, the permissions that you mentioned in your comment being 0x777 are obviously insecure and the Sucuri plugin does not requires anything like that. The only case where it would be required an access so permissive is when your hosting provider configures the web server to run with a different user account than the PHP interpreter, so the later can not read/write in directories where it should, the only solution in this case is either to ask your hosting provider to change the configuration of the whole server (which they will probably refuse) or set the 0x777 permissions on the required directories.

Saying that I (as the sole maintainer of this plugin) do not take security seriously gets to my nerves; sometimes the work I do for this extension is on my free time and not I nor Sucuri is forcing anyone to use this program. I can not control every configuration of every server offered by every hosting provider in the world, if there is one that has a different set of rules people will find a way to throw the blame to the lower player (which in this case seems to be me).

Anyway, @greywolfcomputer if you are still experiencing the issue described in your comment please send a screenshot to [email protected] referencing this ticket and one of my co-workers will forward that email to me. I want to understand what is the directory structure that is making the plugin believe that the integrity of the files that you moved during the migration is broken; maybe because they are in sub-folders but I can not confirm at the time.

First off, that was just a tongue-in-cheek comment. It’s kind of depressing that you’d answer that within a week, but take a month to reply to the issue itself.

The server’s mine. It’s configured correctly, and your suggestion as to *why* this is happening is incorrect. I can tell you that if the permissions on those files are not 777, you can’t do things like manually approve core integrity issues, save last-logins (mine are blank despite hundreds of attempts at using the recent WordPress XML-RPC exploit), trusted IPs, etc.

In any case, I’ve really got to wonder why so many people are having this issue — why store these settings in PHP files in wp-uploads (which is just a bizarre way to do it anyhow) where they can be public-facing at all? Why not just put them in the database? It’d be faster, more secure, and you wouldn’t have to worry about write-errors, or their contents being viewed.

I have limited time to work on this plugin, I have other projects to work on inside the company like CloudProxy [1] and during the last three months there was a lot of things to implement there; giving priority to a project that is developed for free over something that actually produces money for the company does not makes sense. I actually came here tonight (on my free time) per request of a user that asked me via email if I had left the company or something like that because I used to be very responsive in this forum.

Anyway, back to the point of this ticket… As you said you have control over that server where you had to set the permissions of a folder to 0x777 because otherwise the plugin would not work, that is still out of my hands; I test the plugin’s code against five different machines and they were configured to run the web server with the same user as the PHP interpreter so the permissions of the directories are 0x755 and they are writable, a couple of minutes ago I tested again and changed them to be 0x700 and worked as expected.

If you can share the configuration of your server (maybe through a vagrant machine) I could take a look and make the corresponding modifications to the code to either display messages explaining the user how to change the permissions or something like that.

As for your last question of why I am storing information in plain text files in the uploads directory; they are not publicly accessible unless the PHP interpreter is misconfigured, if you open any of those files you will see an exit point in the first line which prevents anyone from the outside to see their content. And considering the amount of security holes found in every WordPress version with SQLi I would not choose to store information in the database even if I were paid for that, better safe than sorry… But I am curious, why do you consider to store information in the database more secure?

[1] https://sucuri.net/website-firewall/

I actually came here tonight (on my free time) per request of a user that asked me via email if I had left the company or something like that because I used to be very responsive in this forum.

…and of the posts of people asking for help, you chose to engage me based on an off-handed comment? o.o

I don’t know what to tell you, but Apache runs PHP as a basic module under the user www-data — standard Debian stuff. And I definitely consider Debian to be the most secure distro for web servers. Anyhow, individual users own their files (because if www-data owned them, they’d get the 7, which would be the same as having them as 777 relative to a web user being able to write files). I mean, just throw up a Debian machine — you don’t need my server config for that. But if the server can write to them, *that* is a security issue. You don’t want the server having the permissions to write to files that have to do with config, because then if there’s any hole anywhere, they can write to them. That’s why the stuff in wp-uploads is typically pictures and whatnot where it wouldn’t cause harm.

Dude, if you’re claiming the database isn’t safe, then they could just hijack whatever they want, log in, and change all the settings. The database is way safer than a world-writable file in a web-facing directory. That’s like… security 101. I have opened those files, and an exit line shouldn’t be all that stands in the way of your configuration printing, especially when that setup makes it so mine can’t even write — hell, in the name of security, if for some reason the plugin *can’t* write to the files, it should be falling back to the database anyhow.

I understand, I know nothing about security; I will send this ticket to the Sucuri development team and one of my co-workers with more experience will clarify the situation; it is almost midnight where I live so this will have to wait until tomorrow, some of my co-workers live in a different timezone so I will send them an email and maybe one of them will get back to you in a few hours.

Will send the screenshot.