Re: Apache not honoring SUID/GUID or FACL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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?




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux