3

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

3
  • Hmmm... This may be better on a different site... maybe unix.stackexchange.com? This isn't really a WordPress question, more of a unix/sysadmin type question... Jan 25, 2012 at 16:06
  • @JohnPBloch I disagree; questions about optimal configuration for ensuring a core WordPress feature - such as automatic upgrades - works properly/optimally should be in-scope for WPSE. Jan 26, 2012 at 16:40
  • @ChipBennett Fair enough. I gladly concede the point. :) Jan 27, 2012 at 0:54

3 Answers 3

1

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.

4
  • Some distros (the Debian flavors, I believe) use www-data:www-data instead of Apache. Obviously, the OP would use apache:apache, but anybody reading this who's using Debian, Ubuntu, etc. will probably have to use www-data instead of apache. Jan 27, 2012 at 0:59
  • Right, but since he stated he's on a Fedora box, I was targeting such... grin
    – ZaMoose
    Feb 7, 2012 at 21:34
  • Indeed. And right you were to do so. My comment was more for the edification of future Debian-based readers. ;) Feb 8, 2012 at 16:16
  • 1
    On our Centos server we use "nobody" as owner. Something like nobody:users does enable the automatic updates. +1 for pointing the way.
    – SPRBRN
    Sep 30, 2013 at 9:10
1

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.

3
  • Hey Chip, thanks for the response. I don't get why that will solve all my issues though. WordPress has no problem running under Apache, since Apache is part of the group that has the r/w permissions. It's a good workaround to the suPHP issue and IMO provides a little more control (and maybe security)?
    – Tom Auger
    Jan 26, 2012 at 16:16
  • Did you read the link? Otto explains, in far greater detail than I could articulate. Jan 26, 2012 at 16:30
  • I did, Chip, in fact I'd already read it quite thoroughly prior to writing this question, just in case the info I needed was in there. I'm quite sure that you're right and that suPHP would probably solve some of my problems, but I don't think it's the complete solution and my current workaround addresses that part of the problem adequately.
    – Tom Auger
    Jan 26, 2012 at 16:35
1

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.

1
  • I don't think it's a shared server -- I think it's a dedicated box (at least that's what I took from his description...).
    – ZaMoose
    Jan 26, 2012 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.