Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
PHP Programming

How to Build, Install, Secure & Optimize PHP 19

geekmedia writes "Open Network Architecture has an excellent article up entitled "How to Build, Install, Secure & Optimize PHP.""
This discussion has been archived. No new comments can be posted.

How to Build, Install, Secure & Optimize PHP

Comments Filter:
  • by DrSkwid ( 118965 ) on Wednesday February 12, 2003 @10:41AM (#5287294) Journal
    I prefer to use PHP in cgi mode and use SUXEC in Apache for virtual hosting.

    I get mod_perl to read the config data in from a database when Apache starts up.

    Our Apache setup (for multiple machines) is then automated with a few HTML forms.

    It also give us the advantage of reducing insecurity with other cgi based programs.

    not perfect performance wise but I think the tradeoff is acceptable.

    • I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host. Everybody seems to do it without any problems but it looks to me as if you simply cannot limit CGI acccess (r/w/x) to be only inside the user dir. The only methods I have tought are using XFS fs's ACL and security patches such as grsecurity and others...but even these are a pain. Having suexec and a user accessible cgi-bin won't help much when the user executes a binary doing "cat /etc/passwd".
      • you are right, of course.

        Not only is it necessary to tighten up the Web Server's security but your whole system has to be configured with that premise in mind.

        CGI here ends up running as $USER:www (you need to have ALL the web users in www so that non-cgi files & directories can be read by the server.)

        I will be honest and confess that I've not finished experimenting with the possibilities. I was hoping that by setting ALL files outside of /www to be chmod nn0 the built in permission testing will take care of that. Hopefully there are no pitfalls in that direction.

        maybe I'd be better going with OpenBSD's chroot'd & jailed Apache [I'm running on FreeBSD atm.]

        anyhow I was also going to see if I could make a bin directory for each user so that they can only execute the files in that directory

        Naturally I have no actual non-staff users with a login on the web server so I've got quite a licence to do whatever I feel is necessary, mis-guided or otherwise 8)

        I only work there one day a week and they would rather me get other stuff done first.

      • I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host.

        We do this using Zeus. Each customer gets his/her own virtual server. Each virtual server is configured to run CGI scripts under a specific uid/gid (that of the customer's account). It works nicely and is very easy to setup.
  • security (Score:5, Insightful)

    by Hard_Code ( 49548 ) on Wednesday February 12, 2003 @10:53AM (#5287384)
    PHP (or anything for that matter) in non-suexec/CGI mode will not be secure for multiple users until the Apache perchild MPM actually works and is officially supported by PHP. This sandboxing of users has long been necessary.
    • As someone who's considering deploying PHP in a multiuser environment and holding off for security concerns, I'm curious to know when you think this will happen.
  • by vbweenie ( 587927 ) <dominic,fox1&ntlworld,com> on Wednesday February 12, 2003 @11:06AM (#5287468) Homepage

    From the article:

    It seems that PHP will certainly replace other language (
    sic) like Perl or CGI for web services in the future. This is due to its simplicity of use and many developers known (sic) about this and has (sic)already developed software that run with PHP on a web server. When you need to add some popular web service to your web server, you will inevitably find that PHP is required and that you need to install it with Apache.

    Three things:

    1. Didn't anyone edit this?
    2. Does the author know what "web services" are? It doesn't sound it...
    3. No, I don't think PHP will "certainly" replace Perl or CGI for web applications; AxKit is one good reason why not, and Perl::Mason is another. And CGI isn't a language.

    Note that I use, and like, PHP and have no axe to grind against the language or its enthusiasts. But this kind of vague, misinformed fluff doesn't give me a lot of confidence in the rest of the article...

    • I managed to actually skip reading the words and skimmed over the content to see what general principles were being introduced.

      That particular paragraph just made me laugh.
      What a loser.

      All that compiling and shuffling files around is markedly different from my experience.

      PHP is inevitable, resistance is futile

      no-one mention that PHP runs just fine on IIS

  • by Ryquir ( 172934 ) on Wednesday February 12, 2003 @12:48PM (#5288256)
    Read through the article and quite frankly this was a sad attempt which should never have gotten beyound the editor stage. First off, since when did IMAP-DEVEL become a required library? Since when did half those libraries become required?

    I guess what ticks me off most is what is not mentioned. How many times does the PHP list have to explain to people that Apache2 DOES NOT work well with PHP. This is a a topic the php support/users lists rehash constantly.

    While some users have been successful in migrating to PHP and Apache2 it is not an easy process by far. One clear issue is that the more 3rd party libraries you include the greater the chances of failure between PHP and Apache2 due to threadsafe issues in 3rd party libraries within PHP. PHP has made clear that this incompatibility is likely to be a long time in the fixing as every library used with PHP needs to be threadsafe. Given that the article asks users to install lots of 3rd party libraries I can't wait to see the list of problems this article creates.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...