7

I'm currently setting up WordPress on an Ubuntu server 12 everything runs fine but there is an issue when it comes to automatically updating and uploading media via WP as Apache "www-data" user does not have permissions to write to the directories. "user1" has full permission

All my directories have permissions of 0755 and files 644

my directories setup is as follows:

/home/user1/public_html

All WP files and directories are in "public_html"

In order to work around the auto updating and uploading media I've granted Apache user ownership to the following directories

sudo chown www-data:www-data wp-content -R
sudo chown www-data:www-data wp-includes -R
sudo chown www-data:www-data wp-admin -R

I would like to know security wise how secure this is and if it is not secure what would be the best solution?

That will allow me to keep all files and directories owned by user1 and still allow wp to be able to automatically update and uploading media

Improve this question

4 Answers 4

Reset to default
3

In my opinion, whether you can consider this safe (not secure), vastly depends on your use case, your users and your environment. Let me put it this way: If you are planing to provide web hosting for paying customers and not happen to be in a closed-down infrastructure or behind an unbelievable sophisticated WAF or IPS, you would probably consider this insecure. Here i am not referring only to the writeable directories, but to using mod_php, which you seem to do. Then again, if you are just setting up a small webhosting for your friends and family, expect some ten hits per week and really have no time, you will be probably be fine (however i would recommend using some available shared hoster, in this case).

More secure alternatives run each user's PHP execution under his own user rights. The most common examples would be:

  • suPHP, which is rather secure, but slow as snail mail.
  • Apache + MPM ITK, which is quite simple to setup but not so widely tested (in contrast to MPM Worker or MPM Prefork). Personally, I would not use this in a production environment.
  • A FastCGI + PHP Environment, either with mod_fastcgi or mod_fcgid.

Depending on your users/environment/..., i would recommend to lock down your box. In the FastCGI scenario you should use chroot and could harden your system further using Linux security enhancements (eg 1, 2, 3).

But once again: You can really spend a good deal of time on this. Consider using a shared-hosted environment from a good hoster, who will do this for you, before putting an insecure box out in the wild.

Improve this answer
3
  • thanks for your informative response, I'm actually setting up this server on Amazon EC2 to be a dedicated server will not be offering shared host to customers. My production site is currently on a shared host but due to limitation i can't scale as I need to I'll do some additional research on your suggested alternatives
    – Oudin
    Commented Jun 26, 2012 at 13:56
  • If you are setting up a single-website/-user system, mod_php is probably an acceptable solution (in terms of simplicity vs performance vs security). Depending on your Linux skills, a complete locked-down box (see above) would still be better, of course. However, securing a single app might be easier. My approach would be (besides patching, patching, patching) a robust WAF. If you need a starting point, try this: blogsecurity.net/wordpress/…
    – ukautz
    Commented Jun 26, 2012 at 19:50
  • I don't have the rep to make smaller edits, but I believe you mean production environment rather than productive?
    – user
    Commented Jun 28, 2012 at 9:27
3

I am almost certain I have answered this before, but I can't find the question to link to.

You shouldn't be asking is it secure if you do nnn. Security is never a binary value, and you almost always need to apply a more detailed analysis. The question you should ask is doing nnn more or less secure then the alternative.

Yes, changing the ownership of files so Apache can write to the does increase the potential for problems, but that simply isn't the only factor.

A much bigger concern if you don't change the ownership, will you be willing to put in the effort to keep the web-application updated and patched. If you don't have the tools or ability to keep it up-to-date and patched using only the CLI, then that is a potentially much larger security problem, then the problems you might have as a result of the more permissive filesystem permissions.

I don't have a link/reference, but I believe I read somewhere that many things are compromised because patches for known vulnerabilities are not applied in a timely manner. OTOH, weak filesystem permissions usually only come into play as a result of a bug/issue in an web application.

Ideally, if you have a requirement for extremely strong paranoid security you would have extremely locked down permissions, and applications very up-to-date, but if I had to choose one, I would generally try to have all the patches installed.

You of course need to make your on decision based on the potential risks, and a realistic understanding of how you will be updating and maintaining the system.

Improve this answer
1
  • Thanks for your response I'm aware that a lot of systems and apps are compromised due to being out dated hence the reason why I have been trying to get the automatic update working to ensure that the time it takes to apply these patches/updates are significantly reduced. I didn't ask "is doing nnn more or less secure then the alternative" because i do not know of any alternatives to compare it too the solution I presented came after hours & days of trial and error. if you know of any alternatives please share
    – Oudin
    Commented Jun 26, 2012 at 2:12
0

EDIT: removed solution that everyone says is "bad".

Leaving this one in place, which everyone chose to ignore because they couldn't read past the first five lines:

Here's the alternative I'm currently experimenting with:

$ chown someuser:other-users somefolder
$ chmod 770 somefolder

That gives the owner (someuser) and all members of group "other-users" (whoever "someuser" decides to give permissions to) read/write/execute permissions. Do chmod 660 for files.

Improve this answer
5
  • 1
    The OP is concerned about making files accessible to the web server group-writeable. Making those files world-writeable is most definitely not better and I'd actually argue that it's much, much worse. Also, in some situations, the commands you suggest for doing so are themselves destructive (they can remove permissions, specifically file execute permissions).
    – user
    Commented Jun 28, 2012 at 9:24
  • 1st, why would you have executables in there anyway? Really? 2nd, see the 2nd part of my answer. And yes, I think the 777 permissions are kind of bad, but they are a solution I see out there all the time. Once again, see my 2nd solution.
    – Buttle Butkus
    Commented Jun 28, 2012 at 9:44
  • Just because it's a "solution" you see out there all the time does not means its best practice or correct. You should never give world executable permissions (or any other world permissions, for that matter) unless you explicitly have to. Doing so opens up the system to major potential exploits.
    – tacotuesday
    Commented Aug 11, 2012 at 4:38
  • I agree with you nojak. That's what in my post I said it was not good practice. Maybe you didn't get that far. I deleted that solution because apparently no one was able to read past it to my second solution, which is probably somewhat better. No?
    – Buttle Butkus
    Commented Aug 11, 2012 at 19:56
  • Apparently I did miss that. I'm glad that you removed it, though, so that future readers don't even get that idea in their heads.
    – tacotuesday
    Commented Aug 16, 2012 at 17:23
-2

Because you config running under mod_php. You have to chown user by cron every 1 minute.

However, you must config running under suphp for your problem

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .