Anon wrote:
Hello :)



My questions can be summarised as :

1) What is the easiest way to install php in CGI mode on OBSD?
Php in CGI mode makes no sense. Php is beloved of his speed against perl for example which is a powerful alternative. We are not going to discuss this here at misc Perl vs PHP so leave with it or change to perl. Php CGI is buggy slow and has many problems to accomplish some tasks thats trivial otherwise.




2) Why doesn't OBSD have a package for php that includes the CGI version?
Not ported as others told u. I don't think there are many that they go this way so probably is no need
3) Why doesn't OBSD have a suphp package? Is there any special reason?
Not ported. I think is crap. My opinion: I can not trust a uid 0 program in my chroot apache to provide security and have it help others may be break out of the jail.


I ask these questions because suphp (http://www.suphp.net) is a program that 
switches the uid of php scripts run under apache, so they run as uid of the 
script owner instead of uid of the webserver. This makes it similar to SuEXEC, 
a very well known security program that does the same thing for perl scripts, 
and is included in the OBSD system. I find it critical to have as a security 
tool, because without it any local user can use php scripts to send mail as 
'nobody' or 'www' - without much in the way of logs, and they can also browse 
the files of other users via scripts... and generally do a lot of things they 
should not be able to do.

I trust my chrooted apache environment on openbsd much more than the suphp package.


As OBSD is focused on security, it makes a lot of sense to me that OBSD would 
at least include the CGI version of PHP in its php-core packages, and 
preferably have a suphp package too.

Thats why apache is chrooted by default in openbsd oposition to a linux system that uses suphp or cgi but is insecure in most cases and by default.

Now, I realise that suphp is mainly made for linux - but I do think it should 
be ported for OBSD, because, frankly, without it, allowing local users to run 
php scripts on your webserver is a very insecure idea. Lots of people run 
webservers on OBSD (like myself) and we're concerned that OBSD provides no 
obvious way to remedy this exploit-waiting-to-happen.
having mini_sendmail for mail and no shell executables in /var/www as is by default or have only some mandatory safe sh script is the secure way to go.


It'd be consistent with your policy of including suexec to also include suphp. 
I'm trying to go with the OBSD guide's advice and only use the packages, but 
this is difficult when there are (imho) essential tools (and even the things 
they depend on) which aren't available as packages :-(



Good luck
Suggestions would be very welcome :)



-Chris

Reply via email to