Changes in the integrity of your core files cannot be restored

The code that powers the file restoration is very simple, it basically contacts the official WordPress repository to retrieve the original content of a specific file, which in this case would be this URL [1]. Considering that WordPress relies in version numbers it would be possible that your site (if it is outdated) is not supported anymore. In the other hand, if you have the latest version then it is possible that the file has no write permissions so the plugin can not replace its content with the official code returned by WordPress.

Anyway, you can always load this URL [1] and replace the version number (4.1.1 in this example) with the one used by your site, and also change the relative path of the file (wp-content/index.php in this example) with the one that you want to restore. Then copy the code that appears and replace everything inside the file located in your site using FTP or the file manager available in your hosting panel.

You can also try to give write permissions to this file to allow the plugin to write in it, that way you do not need to do what I described above but simply use the buttons available in the plugin’s interface. Let me know if this works for you.

[1] https://core.svn.www.ads-software.com/tags/4.1.1/wp-content/index.php

It is a WP 4.1.1 site.

The file atribute was 644. Changed it to 755 and tried repair. Sucuri outputed the following strange notice but the error was still displayed and the file was still intact.

Sucuri: 1 out of 0 files were successfully processed.

The file was restored only when I changed attribute to 777.

1- Isn’t that a bit harsh to require full access to repair a file?
2- That error message needs looking into, me thinks.
3- Maybe you will consider putting a trap to see if there is an attribute error?
4- Logs were showing “Core file restored: /var/www/vhosts/simonmcbride.net/httpdocs/simonmcbride.net/wp/wp-content/index.php” for all the failed tries.

Thanks for listening.

Full Access File Permission

Yes, you are right about that, 0x644 is the correct octal permission in most cases. For people like me that are too paranoid about security 0x600 would be better, and 0x777 is definitely bad. However this only works if the server was configured correctly to separate the permissions among user accounts and to work together with the user that runs the web server.

For example, it is common for some hosting providers to use the “www-data” or “nobody” users to run the web server (lets say Apache as an example). When you upload a file through the web interface (using PHP in this case) the file is uploaded in the server as owned by the user that runs the webserver (www-data or nobody in this example). Considering this scenario you will not be able to modify these uploaded files through your own user account because you do not have write permissions.

If the hosting provider has smart system administrator he will probably configure the server to create an alias between the user that runs the web server and the user of each account, or in some rare cases, configure the server to own these resources by the correct user.

I may be wrong but I believe that the plugin is not able to write in those files because they are owned by your own hosting user account, and the PHP interpreter is running on top of the web server which is being managed by a different account, that is why the 0x644 is not working correctly.

Inconsistent Error Message

You are also right about this one, I will check the code once again to see why the message is not showing the correct numbers, this will be probably fixed for the next version of the plugin.

Attribute Error Trap

I have no idea what do you mind by that, English is not my first language ?? Anyway, I suppose this will not be necessary if I fix the issue with the second point. I am also thinking to include a flag in the table that warns the user that a file is not writable (so it can not be restored nor deleted).

Audit Logs Even With Failed Restoration

I will fix that too, thanks for the report.

The issue occured on a Plesk Ubuntu VPS. That combination is often good in managing file owners/atributes, but as you say it is a tricky point.

I am also thinking to include a flag in the table that warns the user that a file is not writable

That is exactly what I was suggesting by placing a trap. You got it ??

Thank you for listening.

Fixed with changeset 1155457 [1]. You can download the development version [2] of the plugin if you want to test the new changes. Thanks for the suggestion.

[1] https://plugins.trac.www.ads-software.com/changeset/1155457
[2] https://downloads.www.ads-software.com/plugin/sucuri-scanner.zip