One of the ways would be to install http://wordpress.org/extend/plugins/wp-security-scan/ plugin.
This plugin will automatically tell you about the current file permissions and in the case that they’re not correct will also give you proper permission modes as well.
Emil
Thanks!
I’ll do that.
My point was that the Codex itself offers contradictory advice and should be corrected.
I wonder where the plugin author got the information they used to determine “not correct” permissions.
It would be pretty straight-forward to write such a plugin, but with conflicting information from the canonical source, how would you know if it was right?
Thanks,
S
This plugin is using WordPress information and just an FYI it was built by reputable WordPress developer. You can rest assure that it will be the correct one 🙂
Cheers,
Emil
If you want the auto-update to work, then the files have to be owned by the user that the httpd process runs as. This may or may not be your user account.
I’ve edited the Codex page slightly, but due to the many different configurations that are out there, it’s difficult to be highly prescreptive with the information (without getting very deep into detail, at least).
If you want the auto-update to work, then the files have to be owned by the user that the httpd process runs as. This may or may not be your user account.
No, that’s incorrect. The files should be owned by your user account, not the web-user account (if it’s different). Always.
The WordPress updater runs a test to see if it can create files with the same ownership as the files are currently owned by. If it can, then it uses the “direct” method of upgrading. If not, then it asks for FTP credentials in order to be able to write files via that method (which will give them correct ownership).
Files should ALWAYS be owned by the user account. Anything else is insecure.
On shared hosting systems, having files owned by the httpd process account basically allows anybody else with a web account on the server access to modify your files. Not good.
Shared hosting systems that know what they’re doing tend to use a method called “suexec”, which basically means that the PHP process changes its user-account to be running as the owner of the PHP files. Thus, if your files are owned by you, they run as you. This is considered more secure for shared hosting because if somebody hacks your site, then they only have your credentials, not credentials that allow them to access all other sites on the server. Thus, in this case, you want the files to be owned by you as well. In this case, “direct” upgrading works fine, since the php process is running as you, thus it can create files with your ownership properly.
Thanks all for getting into this with me!
The two answers above, also conflicting, illustrate the difficulty I’ve been having.
When the user account owns the files, as @otto said, it does indeed ask for FTP credentials, and downloads and expands the archive properly into the /tmp directory.
Then, in my experience, the update fails to be properly applied as the web server cannot copy the files from /tmp since it doesn’t have write permission to the files since they’re owned by the user (not by the webserver user).
When the webserver owns the files, the automatic upgrade goes fine, but I’m concerned about the security issues.
I am going to look at the permissions set by the http://wordpress.org/extend/plugins/wp-security-scan/ plugin and see which way it goes.
But, how would I know if it were right, regardless of what it does?
Again, this all points to the need for a canonical answer on the Codex that is thorough, detailed, and *correct*.
Thanks all who have contributed to this thread.
S
No, that’s incorrect. The files should be owned by your user account, not the web-user account (if it’s different). Always
Fair enough, I suppose for most environments that will be the case. I’m not sure that the Codex entry as it is now saying that the files should never be owned by the httpd process user is totally correct, though. 😉
@otto — that suexec link is the key — it allows the web server to temporarily run as *you* which would make the second step of copying the files work.
This is probably the missing link that leads to this confusion in the first place. According to the codex, “Shared Hosting with suexec” will allow an FTP-less upgrade, though I’ve yet to know all the pieces to try that out. Now I have enough info, and I own the servers, so I’m going to go do a few experiments.
The codex also gives specific permissions for specific files in that case, so I can go even further.
I’m hoping that the plugin mentioned above takes all of this into account (i.e. detecting suexec) and gives a *working* set of permissions that is as secure as possible.
Again, thanks to all for your help with this. Hopefully the outcome will be a completely correct codex page and, even better, a security audit button right in WordPress.
This is pretty fundamental stuff, obviously isn’t easy to get right, and exactly the type of thing that *should* be automated and included in the product.
Thanks,
S
This is the report given by the WP – Security Admin Tools:
WP – Security Admin Tools
Initial Scan
WordPress version: 3.0.4 You have the latest stable version of WordPress.
Your table prefix should not be wp_. Click here to change it.
Your WordPress version is successfully hidden.
WordPress DB Errors turned off.
WP ID META tag removed form WordPress core
No user “admin”.
The file .htaccess does not exist in wp-admin/.
**WP Security Scan plugin must remain active for security features to remain**
Future Releases
* one-click change file/folder permissions
* test for XSS vulnerabilities
* intrusion detection/prevention
* lock out/log incorrect login attempts
* user enumeration protection
* WordPress admin protection/security
It doesn’t seem that there is any check of file permissions in the current version though it does look like it’s planned for a future release.
S
My mistake, there is another menu choice “Scanner” that does a top-level scan, and shows the file mode, but does not go deep into the tree or check ownership information.
S
So, here’s the result:
All files owned by myuser.
Suexec enabled.
File permissions correct as per WP Security Admin Tool (it only checks top level directory).
——————-
Plugins can be deleted and installed after providing SFTP credentials.
Reinstall of wordpress fails like so:
Update WordPress
Downloading update from http://wordpress.org/wordpress-3.0.4.zip…
Unpacking the update…
Verifying the unpacked files…
Installing the latest version…
Could not copy file.: /public_html/blog-2010-09-22/wp-admin/css/theme-editor.dev.css
Installation Failed
I’m going to go deeper into the file heirarchy to see whether I can figure out which permission setting is causing this failure, but I’m a lot closer (and I think, more secure) than when I just had the webserver user owning everything.
Thanks, more to come, and I’ll be blogging the final result soon.
Thanks,
S
It’s trying to copy files to the wp-content/upgrade directory. Try giving that directory 777 to see if that helps.
The actual copy over the existing files happens via the ftp methods.
Thanks @otto.
I’m sure 777’ing will work, but the goal is to find the most restrictive permissions that still work.
Since I’ve already fiddled with the permissions in various folders, I’m starting at the top again with a fresh Fantastico install, and writing a “Security Tightening” plug-in.
Yes, I know the default Fantastico is not the best for various reasons, but that’s kind of the point. Why would you need a security checker if it was already perfect out of the box?
Looking through the existing plugins (all seven zillion pages of them), none of them really cover all the bases, and most of them don’t have anything to do with securing the installation itself.
I’m going to take everything I know so far, and produce as tight an installation as I can that still works.
S
Well, what I meant was for you to see if making just the upgrade folder 777 would allow it to work. If so, then you at least know the cause of the issue and can adjust permissions downward to see what works and what doesn’t.
Understood.
I really need this to be a one-shot, to lock down sites we sometimes get in pretty bad shape.
That will certainly be something I will try.
Thanks again,
S
