You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Dan <ra...@gmail.com> on 2012/11/02 19:24:50 UTC
[users@httpd] Apache not honoring SUID/GUID or FACL
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Dan <ra...@gmail.com>.
Ben,
I read through the instructions you linked to and I can't find any
differences between my config and the one the author suggested. Point of
fact, that site was one of the ones that I used when researching my own
config.
After taking (yet another) look at the config, I decided to disable
Kerberos authentication (which we use for SSO) and run the same tests with
mod_php and mod_fastcgi, and the difference is astonishing. Kerberos auth
using a fastcgi configuration doesn't seem to scale well and performance
gets dramatically worse with more concurrent sessions.
Conversely, with kerb disabled the average response time is 150 ms, and the
response time with mod_fastcgi is 200 ms. These findings concur with your
earlier statement that mod_fastcgi should only be 20% slower (in this case
25%, but still...).
So here's the synopsis:
*With Kerb* *Without Kerb*
Mod_PHP: 1600 ms 160 ms
Mod_FastCGI 4400 ms 210 ms
I believe we're far enough from the original question to justify a
different thread, but if you (or anyone else) have any suggestions for
remedying this, I'd love to hear them. I've done some googling already and
found references to disabling SELinux, but it's already disabled on this
system.
Thanks for your help!
Dan
On Fri, Nov 9, 2012 at 9:47 AM, Ben Johnson <be...@indietorrent.org> wrote:
>
>
> On 11/9/2012 9:21 AM, Dan wrote:
>> Ok folks. I've got this working but performance with mod_fastCGI but I'm
>> disappointed with the results compared to mod_php. I know mod_php is
>> supposed to be the fastest option, but fastcgi is on average 60% slower
>> than mod_php, so I'm hoping someone can verify my configuration.
>
> My experience has been that FastCGI is definitely slower, but 60% seems
> to be a considerable variance. The difference I've observed is more like
> 20%, but performance variances are often largely server configuration
> and application specific.
>
> I recommend reading through
>
> http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/
>
> if you haven't already, and ensuring that APC is, in fact, effective.
> Also, my understanding is that using APC in such a configuration is very
> RAM-intensive, as there is a dedicated cache for each user.
>
> In fact, you may be interested in the same author's benchmarking and
> performance follow-up article:
>
>
http://www.brandonturner.net/blog/2009/07/fastcgi_php_opcode_cache_benchmarks/
>
> Disclaimer: I'm in no way affiliated with brandonturner.net; I just
> found the articles useful in my own work.
>
> I'm sure that many of us would be curious to hear back from you once
> you've tinkered a bit more.
>
> Good luck!
>
> -Ben
>
>
>
>> I added the following to my main config:
>>
>> LoadModule fastcgi_module modules/mod_fastcgi.so
>> FastCgiWrapper On
>> FastCgiIpcDir /var/run/fastcgi
>> FastCgiConfig -idle-timeout 20 -maxClassProcesses 1
>>
>>
>> I also added the following to my vhost block:
>>
>> SuexecUserGroup wp-itghome www
>> DirectoryIndex index.php
>> AddHandler php5-fastcgi .php
>> Action php5-fastcgi /cgi-itghome-dev/php-fcgi
>> ScriptAlias /cgi-itghome-dev "/var/www/cgi-itghome-dev/"
>> FastCgiServer /var/www/cgi-itghome-dev/php-fcgi -socket
>> /var/run/fastcgi/fastcgi-itghome-dev.socket -user wp-itghome -group
>> www -idle-timeout 310 -flush
>> <Directory "/var/www/cgi-itghome-dev">
>> AllowOverride none
>> Options None
>> Order allow,deny
>> Allow from all
>> </Directory>
>> <Location /cgi-itghome-dev>
>> Order Deny,Allow
>> Deny from All
>> Allow from env=REDIRECT_STATUS
>> </Location>
>>
>>
>> The socket file specified above is owned by apache, and the contents of
>> /var/www/cgi-itghome-dev are all owned by the wp-itghome-dev user and
>> "www" group. Site content loads properly and APC reports it's using the
>> same cache file for every request so it seems to be working.
>>
>> The server in question has a single CPU (3 Ghz) and 2 GB of RAM. I used
>> apache bench to performance-test the VM, having it request phpinfo.php
>> from 100-1000 times, with the test scaling 100 requests at a time and
>> with 100 of those requests concurrent. At peak, this site would
>> reasonably have to accommodate 100 concurrent users, so I figured this
>> was appropriate.
>>
>> The test results with mod_php show an average response time of 1600 ms,
>> and with mod_fastcgi it was almost 4400 ms. Watching top during tests
>> shows a lot of httpd processes waiting for I/O, I assume because of
>> contention for the socket file. To mitigate that I also tried setting
>> fastcgi to listen on a tcp port instead of using a socket file and
>> performance was worse, on average 6000 ms.
>>
>> Can someone tell me whether this performance differential is to be
expected?
>>
>> Thanks,
>>
>> Dan
>>
>>
>>
>> On Wed, Nov 7, 2012 at 9:19 AM, Dan <random.danno@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Thanks Noel.
>>
>> We can use VSFTPD for developer access post-install via WordPress,
>> and could in theory use umask in the apache startup script to set
>> apache's umask (even though as stated in my OP that it wasn't
>> working), but I'd rather not set up an FTP daemon and stick with
>> chrooted SFTP access instead.
>>
>> I have gotten PHP as a (standard) CGI with the "SuexecUserGroup"
>> directive working to set the correct ownership on uploaded plugins,
>> but we use APC (Alternate PHP Cache) as our opcode cache and this
>> doesn't work with standard PHP-CGI deployments. ApacheBench testing
>> shows an increase of approximately 1 second response time per
>> request when APC isn't used, so that's a deal-breaker for me. SuPHP
>> appears to have the same limitation, so it's not an option either.
>>
>> At this time I'm evaluating mod_fastcgi, which supposedly works with
>> SuExec and APC. If anyone has an input or past-difficulties with
>> this proposed deployment, I'd appreciate hearing from you.
>>
>> Dan
>>
>>
>>
>> On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <noel.butler@ausics.net
>> <ma...@ausics.net>> wrote:
>>
>> __
>> On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
>>> 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.
>>>
>>
>> suexec is perfect for any number of hosts, but I assume you mean
>> the phpsuexec stuff, which you are in fact correct, it, along
>> with suphp, introduce serious performance hits if you have more
>> than a few hundred vhosts, and given most hosts run a couple of
>> thousands vhosts per typical, say DL380 type machine, you will
>> notice it, and your customers will notice it - especially if the
>> machine has many busy sites.
>>
>> thats why most large sites use php admin value flags for locking
>> them down, but some php plugins that are poorly written dont
>> always honour those restrictions, which is where suhosin comes
>> in to try fill the gap ( although I think its mod_php's job to
>> be more anal about what it allows) in trying to catch those
>> uselessly written extensions for doing stuff you dont want it
>> to, even in this configuration, it wont be 100% secure, but it
>> certainly is not 100% secure using other methods either, suphp
>> for instance although not too bad in past couple years, has had
>> a poor history in the past.
>>
>>
>>
>>> I'm looking into SuPHP right now, but their site _seems_ to be
down.
>>>
>>
>> :)
>>
>>
>> setfacl chmod etc are no good, they only set existing, you need
>> to work with umasks, it is not possible to have apache set umask
>> in virtualhosts, a dirty way would be to set the umask in the
>> init script for httpd, but I would not recommend that since
>> allowing httpd to group write access, will introduce major
>> security issues for all vhosts. You are better off circumventing
>> this via ftp, what ftpd are you using?
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Ben Johnson <be...@indietorrent.org>.
On 11/9/2012 9:21 AM, Dan wrote:
> Ok folks. I've got this working but performance with mod_fastCGI but I'm
> disappointed with the results compared to mod_php. I know mod_php is
> supposed to be the fastest option, but fastcgi is on average 60% slower
> than mod_php, so I'm hoping someone can verify my configuration.
My experience has been that FastCGI is definitely slower, but 60% seems
to be a considerable variance. The difference I've observed is more like
20%, but performance variances are often largely server configuration
and application specific.
I recommend reading through
http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/
if you haven't already, and ensuring that APC is, in fact, effective.
Also, my understanding is that using APC in such a configuration is very
RAM-intensive, as there is a dedicated cache for each user.
In fact, you may be interested in the same author's benchmarking and
performance follow-up article:
http://www.brandonturner.net/blog/2009/07/fastcgi_php_opcode_cache_benchmarks/
Disclaimer: I'm in no way affiliated with brandonturner.net; I just
found the articles useful in my own work.
I'm sure that many of us would be curious to hear back from you once
you've tinkered a bit more.
Good luck!
-Ben
> I added the following to my main config:
>
> LoadModule fastcgi_module modules/mod_fastcgi.so
> FastCgiWrapper On
> FastCgiIpcDir /var/run/fastcgi
> FastCgiConfig -idle-timeout 20 -maxClassProcesses 1
>
>
> I also added the following to my vhost block:
>
> SuexecUserGroup wp-itghome www
> DirectoryIndex index.php
> AddHandler php5-fastcgi .php
> Action php5-fastcgi /cgi-itghome-dev/php-fcgi
> ScriptAlias /cgi-itghome-dev "/var/www/cgi-itghome-dev/"
> FastCgiServer /var/www/cgi-itghome-dev/php-fcgi -socket
> /var/run/fastcgi/fastcgi-itghome-dev.socket -user wp-itghome -group
> www -idle-timeout 310 -flush
> <Directory "/var/www/cgi-itghome-dev">
> AllowOverride none
> Options None
> Order allow,deny
> Allow from all
> </Directory>
> <Location /cgi-itghome-dev>
> Order Deny,Allow
> Deny from All
> Allow from env=REDIRECT_STATUS
> </Location>
>
>
> The socket file specified above is owned by apache, and the contents of
> /var/www/cgi-itghome-dev are all owned by the wp-itghome-dev user and
> "www" group. Site content loads properly and APC reports it's using the
> same cache file for every request so it seems to be working.
>
> The server in question has a single CPU (3 Ghz) and 2 GB of RAM. I used
> apache bench to performance-test the VM, having it request phpinfo.php
> from 100-1000 times, with the test scaling 100 requests at a time and
> with 100 of those requests concurrent. At peak, this site would
> reasonably have to accommodate 100 concurrent users, so I figured this
> was appropriate.
>
> The test results with mod_php show an average response time of 1600 ms,
> and with mod_fastcgi it was almost 4400 ms. Watching top during tests
> shows a lot of httpd processes waiting for I/O, I assume because of
> contention for the socket file. To mitigate that I also tried setting
> fastcgi to listen on a tcp port instead of using a socket file and
> performance was worse, on average 6000 ms.
>
> Can someone tell me whether this performance differential is to be expected?
>
> Thanks,
>
> Dan
>
>
>
> On Wed, Nov 7, 2012 at 9:19 AM, Dan <random.danno@gmail.com
> <ma...@gmail.com>> wrote:
>
> Thanks Noel.
>
> We can use VSFTPD for developer access post-install via WordPress,
> and could in theory use umask in the apache startup script to set
> apache's umask (even though as stated in my OP that it wasn't
> working), but I'd rather not set up an FTP daemon and stick with
> chrooted SFTP access instead.
>
> I have gotten PHP as a (standard) CGI with the "SuexecUserGroup"
> directive working to set the correct ownership on uploaded plugins,
> but we use APC (Alternate PHP Cache) as our opcode cache and this
> doesn't work with standard PHP-CGI deployments. ApacheBench testing
> shows an increase of approximately 1 second response time per
> request when APC isn't used, so that's a deal-breaker for me. SuPHP
> appears to have the same limitation, so it's not an option either.
>
> At this time I'm evaluating mod_fastcgi, which supposedly works with
> SuExec and APC. If anyone has an input or past-difficulties with
> this proposed deployment, I'd appreciate hearing from you.
>
> Dan
>
>
>
> On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <noel.butler@ausics.net
> <ma...@ausics.net>> wrote:
>
> __
> On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
>> 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.
>>
>
> suexec is perfect for any number of hosts, but I assume you mean
> the phpsuexec stuff, which you are in fact correct, it, along
> with suphp, introduce serious performance hits if you have more
> than a few hundred vhosts, and given most hosts run a couple of
> thousands vhosts per typical, say DL380 type machine, you will
> notice it, and your customers will notice it - especially if the
> machine has many busy sites.
>
> thats why most large sites use php admin value flags for locking
> them down, but some php plugins that are poorly written dont
> always honour those restrictions, which is where suhosin comes
> in to try fill the gap ( although I think its mod_php's job to
> be more anal about what it allows) in trying to catch those
> uselessly written extensions for doing stuff you dont want it
> to, even in this configuration, it wont be 100% secure, but it
> certainly is not 100% secure using other methods either, suphp
> for instance although not too bad in past couple years, has had
> a poor history in the past.
>
>
>
>> I'm looking into SuPHP right now, but their site _seems_ to be down.
>>
>
> :)
>
>
> setfacl chmod etc are no good, they only set existing, you need
> to work with umasks, it is not possible to have apache set umask
> in virtualhosts, a dirty way would be to set the umask in the
> init script for httpd, but I would not recommend that since
> allowing httpd to group write access, will introduce major
> security issues for all vhosts. You are better off circumventing
> this via ftp, what ftpd are you using?
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Dan <ra...@gmail.com>.
Ok folks. I've got this working but performance with mod_fastCGI but I'm
disappointed with the results compared to mod_php. I know mod_php is
supposed to be the fastest option, but fastcgi is on average 60% slower
than mod_php, so I'm hoping someone can verify my configuration.
I added the following to my main config:
LoadModule fastcgi_module modules/mod_fastcgi.so
> FastCgiWrapper On
> FastCgiIpcDir /var/run/fastcgi
> FastCgiConfig -idle-timeout 20 -maxClassProcesses 1
>
I also added the following to my vhost block:
SuexecUserGroup wp-itghome www
> DirectoryIndex index.php
> AddHandler php5-fastcgi .php
> Action php5-fastcgi /cgi-itghome-dev/php-fcgi
> ScriptAlias /cgi-itghome-dev "/var/www/cgi-itghome-dev/"
> FastCgiServer /var/www/cgi-itghome-dev/php-fcgi -socket
> /var/run/fastcgi/fastcgi-itghome-dev.socket -user wp-itghome -group www
> -idle-timeout 310 -flush
> <Directory "/var/www/cgi-itghome-dev">
> AllowOverride none
> Options None
> Order allow,deny
> Allow from all
> </Directory>
> <Location /cgi-itghome-dev>
> Order Deny,Allow
> Deny from All
> Allow from env=REDIRECT_STATUS
> </Location>
>
The socket file specified above is owned by apache, and the contents of
/var/www/cgi-itghome-dev are all owned by the wp-itghome-dev user and "www"
group. Site content loads properly and APC reports it's using the same
cache file for every request so it seems to be working.
The server in question has a single CPU (3 Ghz) and 2 GB of RAM. I used
apache bench to performance-test the VM, having it request phpinfo.php from
100-1000 times, with the test scaling 100 requests at a time and with 100
of those requests concurrent. At peak, this site would reasonably have to
accommodate 100 concurrent users, so I figured this was appropriate.
The test results with mod_php show an average response time of 1600 ms, and
with mod_fastcgi it was almost 4400 ms. Watching top during tests shows a
lot of httpd processes waiting for I/O, I assume because of contention for
the socket file. To mitigate that I also tried setting fastcgi to listen on
a tcp port instead of using a socket file and performance was worse, on
average 6000 ms.
Can someone tell me whether this performance differential is to be expected?
Thanks,
Dan
On Wed, Nov 7, 2012 at 9:19 AM, Dan <ra...@gmail.com> wrote:
> Thanks Noel.
>
> We can use VSFTPD for developer access post-install via WordPress, and
> could in theory use umask in the apache startup script to set apache's
> umask (even though as stated in my OP that it wasn't working), but I'd
> rather not set up an FTP daemon and stick with chrooted SFTP access instead.
>
> I have gotten PHP as a (standard) CGI with the "SuexecUserGroup" directive
> working to set the correct ownership on uploaded plugins, but we use APC
> (Alternate PHP Cache) as our opcode cache and this doesn't work with
> standard PHP-CGI deployments. ApacheBench testing shows an increase of
> approximately 1 second response time per request when APC isn't used, so
> that's a deal-breaker for me. SuPHP appears to have the same limitation, so
> it's not an option either.
>
> At this time I'm evaluating mod_fastcgi, which supposedly works with
> SuExec and APC. If anyone has an input or past-difficulties with this
> proposed deployment, I'd appreciate hearing from you.
>
> Dan
>
>
>
> On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <no...@ausics.net>wrote:
>
>> **
>> On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
>>
>> 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.
>>
>>
>>
>> suexec is perfect for any number of hosts, but I assume you mean the
>> phpsuexec stuff, which you are in fact correct, it, along with suphp,
>> introduce serious performance hits if you have more than a few hundred
>> vhosts, and given most hosts run a couple of thousands vhosts per typical,
>> say DL380 type machine, you will notice it, and your customers will notice
>> it - especially if the machine has many busy sites.
>>
>> thats why most large sites use php admin value flags for locking them
>> down, but some php plugins that are poorly written dont always honour
>> those restrictions, which is where suhosin comes in to try fill the gap (
>> although I think its mod_php's job to be more anal about what it allows) in
>> trying to catch those uselessly written extensions for doing stuff you dont
>> want it to, even in this configuration, it wont be 100% secure, but it
>> certainly is not 100% secure using other methods either, suphp for instance
>> although not too bad in past couple years, has had a poor history in the
>> past.
>>
>>
>>
>> I'm looking into SuPHP right now, but their site _seems_ to be down.
>>
>>
>>
>> [image: :)]
>>
>>
>> setfacl chmod etc are no good, they only set existing, you need to work
>> with umasks, it is not possible to have apache set umask in virtualhosts, a
>> dirty way would be to set the umask in the init script for httpd, but I
>> would not recommend that since allowing httpd to group write access, will
>> introduce major security issues for all vhosts. You are better off
>> circumventing this via ftp, what ftpd are you using?
>>
>>
>>
>
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Dan <ra...@gmail.com>.
Thanks Noel.
We can use VSFTPD for developer access post-install via WordPress, and
could in theory use umask in the apache startup script to set apache's
umask (even though as stated in my OP that it wasn't working), but I'd
rather not set up an FTP daemon and stick with chrooted SFTP access instead.
I have gotten PHP as a (standard) CGI with the "SuexecUserGroup" directive
working to set the correct ownership on uploaded plugins, but we use APC
(Alternate PHP Cache) as our opcode cache and this doesn't work with
standard PHP-CGI deployments. ApacheBench testing shows an increase of
approximately 1 second response time per request when APC isn't used, so
that's a deal-breaker for me. SuPHP appears to have the same limitation, so
it's not an option either.
At this time I'm evaluating mod_fastcgi, which supposedly works with SuExec
and APC. If anyone has an input or past-difficulties with this proposed
deployment, I'd appreciate hearing from you.
Dan
On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <no...@ausics.net> wrote:
> **
> On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
>
> 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.
>
>
>
> suexec is perfect for any number of hosts, but I assume you mean the
> phpsuexec stuff, which you are in fact correct, it, along with suphp,
> introduce serious performance hits if you have more than a few hundred
> vhosts, and given most hosts run a couple of thousands vhosts per typical,
> say DL380 type machine, you will notice it, and your customers will notice
> it - especially if the machine has many busy sites.
>
> thats why most large sites use php admin value flags for locking them
> down, but some php plugins that are poorly written dont always honour
> those restrictions, which is where suhosin comes in to try fill the gap (
> although I think its mod_php's job to be more anal about what it allows) in
> trying to catch those uselessly written extensions for doing stuff you dont
> want it to, even in this configuration, it wont be 100% secure, but it
> certainly is not 100% secure using other methods either, suphp for instance
> although not too bad in past couple years, has had a poor history in the
> past.
>
>
>
> I'm looking into SuPHP right now, but their site _seems_ to be down.
>
>
>
> [image: :)]
>
>
> setfacl chmod etc are no good, they only set existing, you need to work
> with umasks, it is not possible to have apache set umask in virtualhosts, a
> dirty way would be to set the umask in the init script for httpd, but I
> would not recommend that since allowing httpd to group write access, will
> introduce major security issues for all vhosts. You are better off
> circumventing this via ftp, what ftpd are you using?
>
>
>
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Noel Butler <no...@ausics.net>.
On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
> 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.
>
suexec is perfect for any number of hosts, but I assume you mean the
phpsuexec stuff, which you are in fact correct, it, along with suphp,
introduce serious performance hits if you have more than a few hundred
vhosts, and given most hosts run a couple of thousands vhosts per
typical, say DL380 type machine, you will notice it, and your customers
will notice it - especially if the machine has many busy sites.
thats why most large sites use php admin value flags for locking them
down, but some php plugins that are poorly written dont always honour
those restrictions, which is where suhosin comes in to try fill the gap
( although I think its mod_php's job to be more anal about what it
allows) in trying to catch those uselessly written extensions for doing
stuff you dont want it to, even in this configuration, it wont be 100%
secure, but it certainly is not 100% secure using other methods either,
suphp for instance although not too bad in past couple years, has had a
poor history in the past.
> I'm looking into SuPHP right now, but their site _seems_ to be down.
>
:)
setfacl chmod etc are no good, they only set existing, you need to work
with umasks, it is not possible to have apache set umask in
virtualhosts, a dirty way would be to set the umask in the init script
for httpd, but I would not recommend that since allowing httpd to group
write access, will introduce major security issues for all vhosts. You
are better off circumventing this via ftp, what ftpd are you using?
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Dan <ra...@gmail.com>.
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 <be...@indietorrent.org> 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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache not honoring SUID/GUID or FACL
Posted by Ben Johnson <be...@indietorrent.org>.
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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org