I’ve been reading some posts that seem to touch on this (or possibly address it, but it’s going over my head). Unix is not my strong suit by a long shot.
I have inherited a Fedora server that is a little bumpy when it comes to auto upgrades.
Two things I’ve noticed:
1. It prompts me for FTP user and password. I’d like to eliminate this WITHOUT resorting to hard-coding the credentials (for a number of reasons)
2. The most recent 3.3.1 update fails for permission reasons (earlier upgrades did not fail). The workaround is to sudo chmod -R g+w ./* in the main wp directory, but I’m kind of sick of doing that every time.
Bottom line: things WORK, but it’s more work than I’d like.
Right now, everything seems to be running under the ‘apache’ user, which is a member of my ‘developers’ group that is the same group for the various people that FTP and make changes/edits to files/folders. But any new files/folders that are created by these users do not have their group write mode set so I have to do it manually…
Any thoughts? I’ll need a bit of a step-by-step since I’m a unix moron.
Thanks!
T
The simplest answer is:
As long as you’re on a fairly standard RedHat/CentOS/Fedora server, make sure that everything under your WordPress directory belongs to apache:apache. This will prevent the prompting for FTP credentials.
The advantage to doing it this way is that, in almost ALL situations, Apache has /bin/false or /sbin/nologin set up as its shell. This prevents anyone from exploiting the apache user to gain shell access to your box.
I think you’re likely getting tripped up by directories inheriting permissions from users with valid shells whose umasks are set funny. Try chown’ing everything to apache:apache and do a couple of test updates and see if that doesn’t fix 99% of the issues you’re running into.
The short answer is to enable suPHP on your server, so that WordPress can run as its own user, rather than as apache.
Otto explains more here.
The answer to this is rather complicated.
On a shared server (running more than one website), using an setuid process for PHP (via whatever means) provides extra intra-user security. If two people have access to a server, and their scripts run as them instead of as a single “apache” user, then somebody breaking into one site via the web only gains the privs of that user, not the privs of “apache”, which will be greater (apache can see everybody’s web files, for example, in order to run them, but “otto” can’t see the files of “bob”).
In this case, WordPress will be running as “otto” and not “apache”. Since it’s running as “otto” and the WP files are owned by “otto”, then it can just write the files directly and doesn’t need FTP credentials.
See, it’s all about ownership. If the files are owned by the same user who WP is actually running as, then it will use the direct method. If not, then it has to fall back to the FTP method (or other), because the important thing during an upgrade is that file ownership does not change. If it tried to write them directly as the apache user, then “apache” would own the resulting files. Which might be a security risk on a dedicated server.
For a dedicated server, having the files owned by a non-apache user while having the PHP run under ‘apache’ is safest. Perhaps even setting up a special user just for owning those files might be preferable and securer in such a situation. Then the credentials to upgrade could be put into the wp-config file, and even if they were stolen in some manner, wouldn’t pose a threat since those credentials could be locked down to where they had virtually no access to anything but the WP files themselves. Then if somebody did break in, they’d either break in as “apache” (which has limited privs) or be able to execute code as the custom WP user (which also has limited privs).
The idea is to limit the capabilities of a user who finds a hole in the system. When somebody finds a weak spot, then they will be further limited by the privileges of the user that the process they broke through with is running as.