Ben, Yes you're right, we are using mod_php, but only because no other alternative was required up to this point. This server hosts many vhosts, and I've read that SuEXEC isn't appropriate for multi-site installations of apache. I'm looking into SuPHP right now, but their site _seems_ to be down. Thanks again... Dan On Fri, Nov 2, 2012 at 1:44 PM, Ben Johnson <ben@xxxxxxxxxxxxxxxx> wrote: > > > On 11/2/2012 2:24 PM, Dan wrote: >> Hello all... >> >> I have a Apache 2.2.15 install serving a Wordpress 3.4.2 site. I also >> have a developer who needs to occasionally overwrite a specific file >> in a plugin directory by FTP or SFTP. >> >> The issue I have is that newly installed plugins (installed via the >> Wordpress UI) are written to the plugins directory with the "apache" >> user as the owner/group of the files. The plugins directory is owned >> (user and group) by the developer, whose UID is "itghome". >> >> -rw-r--r-- 1 itghome itghome 28 Jan 8 2012 index.php >> drwsrwsr-x+ 11 itghome itghome 4096 Nov 2 13:04 plugins >> drwxrwxr-x 6 itghome itghome 4096 Sep 24 13:51 themes >> drwxrwxr-x 2 itghome itghome 4096 Nov 2 13:04 upgrade >> drwsrwsr-x 3 itghome itghome 4096 Sep 22 11:26 uploads >> >> Any newly created directory under plugins is missing the group write >> flag, so the developer is unable to overwrite any of the files placed >> there by Wordpress. >> >> I've tried setting the SUID and GUID bits on "plugins", hoping that >> newly created sub-directories would inherit the ownership of the >> plugins directory. But when I install a new plugin, it only seems to >> inherit group ownership and only on the top-level directory for the >> plugin. Everything below that is owned by "apache" (user and group). >> >> I then tried setting an facl on the plugins directory (which you can >> see above), but Apache doesn't seem to be honoring that either. >> >> Here's the syntax I used to set the facl: >> >> # setfacl -R -m d:u::rwx,d:g::rwx,d:m::rwx,d:o:r-x plugin >> >> Here's what getfacl reports: >> >> # getfacl plugins >> # file: plugins >> # owner: itghome >> # group: itghome >> # flags: ss- >> user::rwx >> group::rwx >> group:itghome:rwx >> mask::rwx >> other::r-x >> default:user::rwx >> default:group::rwx >> default:group:itghome:rwx >> default:mask::rwx >> default:other::r-x >> >> Once again, after adding a plugin through WordPress the plugin >> directory permissions aren't changed to reflect the GUID or facl. >> >> I've even experimented with setting the umask for apache by adding >> "umask 002" to the /etc/sysconfig/httpd file, but after a restart >> apache still doesn't write the files with the correct ownership/perms. >> I've seen this discussed on WordPress forums and it seems WordPress' >> take is that this is all the responsibility of the web-server, and >> they suggest setting Apache's umask. Can anyone tell me if this has >> more to do with the way the plugins are extracted into the plugin >> directory (the plugin is a zip file). or whether this is a limitation >> apache implements for security purposes? If so, what other options do >> I have? >> >> Thanks in advance... >> >> Dan > > Hi, Dan, > > Presumably, PHP is running as an Apache module (e.g., mod_php) for this > particular (v)host. Do you have a specific reason for sticking to mod_php? > > Because if you simply switched to CGI or FastCGI + suExec, suPHP, etc., > Apache processes associated with that (v)host would run under a > configurable UID/GUID, which means that WordPress plug-ins would be > installed with the same user and group. Then you could add your > developer's user account to the appropriate group and the problem should > be solved. > > Just one approach of many, I'm sure. > > -Ben > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|