3

So, I have a box with a "deploy" user. This deploy user owns a code repository and wordpress is running on this box...

When wordpress attempts to do something like upload a plugin, it is using the user "www-data" to write to "wp-content/plugins".. Apparently it is uploading a zipfile, unarchiving, and then removing the zipfile.

I kept running into problems where wordpress was unable to do these things.. Since my entire code repository was set to be the owner and group: "deploy:deploy", obviously www-data is not able to access this.

So, my first attempt was to add www-data to the deploy group.

usermod -a -G deploy www-data

Immediately after issuing this command, I found that I could no longer ssh into the box.. Totally confused as to why-- can anyone fill me in on that? So I ended up doing:

chmod -R go-w ~

And then could ssh in again... doing "groups www-data" showed deploy as one of the options, so I thought hooray... I went and made sure the wp-content and plugin directories all had write access for the group, and they did... Double horray, it should work perfectly!

However, no... Failure upon trying to upload a plugin.

After much annoyance, I just went into the apache config and changed the APACHE_RUN_USER & GROUP to "deploy"

Problem solved... Sort of. Except the idea of apache running as the main user, I think is awful.

Anyway, so after making this change, uploading a plugin was successful and I saw:

drwxr-xr-x 8 deploy deploy 4096 Oct 22 21:28 wp-crm

So, the group has no write access-- I thought maybe this is a hint to why this was failing... But then, the fact that it's writing with deploy, means that's not really a hint... Because that's just due to how deploy's umask is set to.. I assume...

So... I am just lost as to what the solution is...

Should my wp-content group be www-data instead?

Or am I missing something else here?

Improve this question
1
  • If you use something CGI-based with suexec, then php code can be executed as another user. The reason it is www-data is because the php code is being interpreted by apache itself, via mod_php. Commented Oct 23, 2012 at 2:09

2 Answers 2

Reset to default
1

The simplest solution to this would be filesystem ACLs. I'm not sure I agree with the setup (because the directory isn't static, and it's not using some other directory for temp data), but that's another matter.

With filesystem ACLs, you can grant the www-data user access to a specific directory, even though the normal permissions dont allow it.

So for example

setfacl -R -m user:www-data:rwx wp-content/plugins setfacl -d -R -m user:www-data:rwx wp-content/plugins

The first command grant's www-data read+write+execute to wp-content/plugins and everything in it (recursively). The second command sets the default permissions so that any new files and folders created in wp-content/plugins will have the specified ACL (and thus be read+write+execute by www-data).

Improve this answer
1

Unfortunately usermod -G replaces the user's groups. You wanted usermod -G -a.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.