[closed] Litespeed 4.0.18 + PHP FastCGI + Suexec issues

#1
Hi to all forum members.

Let's start with the requirements first:

>> a. OS Version (Linux/FreeBSD/Solaris, distribution, kernel, 32bit/64bit)

CentOS 5.5 - 32bit

>> b. Hardware configurations: CPU speed, RAM size, etc

Unrelated

>> c. LiteSpeed version (also standard or enterprise)

LiteSpeed/4.0.18 Enterprise
- Using Apache Configuration File -> YES
- PHP suEXEC -> YES
- PHP script handler set to -> FastCGI with custom build PHP

>> Licensing

Trial Key

>> PHP information (PHPinfo page is preferred), run in suEXEC mode or not?

Applies to all of the following:

PHP 4.4.9 - fcgi
PHP 5.0.5 - fcgi
PHP 5.1.6 - fcgi
PHP 5.2.17 - fcgi
PHP 5.3.5 - fcgi

Suexec --> Yes but it is not working

>> e. Hosting control panel if used, including version number

cPanel

>> Detailed Description of the problem

We have been evaluating litespeedhttpd product with a _trail_ license and we found an issue we have been struggling on for 2 days now. We will greatly
appreciate your thoughts on it.

When the PHP extensions are set to be processed by the LSAPI App each
PHP process is executed with the owner of the docroot folder which is
exactly what we expect. This clones the "suexec" like behavior in apache.

However when we switch PHP extensions to be processed by the FastCGI
handler all PHP processes are executed with the user under which
litespeed is running on (nobody in our case).

We did a lot of research and all articles we read says that
fastcgi processed php scripts CAN be executed in "suexec" like mode. We tried all possible configurations. None of these helped.

When we strace/ltrace the litespeed processes it seems that when we are using fastcgi the fastcgi configured php is never executed via lscgid (the
daemon which handles the suexec like behavior in this product we
suppose). However when we switch to lsapi phps we can see that the
requests are passed to lscgid first and handled by the phps itself after
the lscgid setuid to the owner of the docroot folder.

We turned on the debug mode of the litespeed web server. Below you can
find the output from the processing a sample PHP script via lsapi php:

2011-01-18 02:02:36.560 [DEBUG] [HTAccess] Updating configuration file
[/home/support/public_html/.htaccess]
2011-01-18 02:02:36.561 [DEBUG]
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com] [REWRITE] Rewrite engine is
not enabled for context '/'
2011-01-18 02:02:36.561 [DEBUG]

Note the suphp5 mentioned on this line here:

[xxx.xxx.xxx.xxx:44669-0#APVH_support.com] Find handler
[APVH_support_Suphp5:] for [.php5]

All lines below are also showing that the process is handled in a suexec
like mode what we want and works fine with the lsapi

2011-01-18 02:02:36.561 [DEBUG]
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com] processContextPath() return 0
2011-01-18 02:02:36.561 [DEBUG]
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com] run lsapi processor.
2011-01-18 02:02:36.561 [DEBUG]
[uds://tmp/lshttpd/APVH_support.com_Suphp5.sock] create new connection
succeed!
2011-01-18 02:02:36.561 [DEBUG]
[uds://tmp/lshttpd/APVH_support.com_Suphp5.sock] request
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com:lsapi] is assigned with
connection!
2011-01-18 02:02:36.561 [DEBUG]
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com:lsapi] [ExtConn] reconnect()

All lines below shows suphp sockets (handled by lscgid we suppose)

2011-01-18 02:02:36.561 [INFO] Start listen socket
[/tmp/lshttpd/APVH_support.com_Suphp5.sock].
2011-01-18 02:02:36.561 [INFO] [APVH_support_Suphp5:] pid list size: 1
2011-01-18 02:02:36.561 [INFO] [APVH_support_Suphp5:] add child process
pid: 5075
2011-01-18 02:02:36.561 [DEBUG]
[xxx.xxx.xxx.xxx:44669-0#APVH_support.com:lsapi] [ExtConn] connecting to
[uds://tmp/lshttpd/APVH_support.com_Suphp5.sock]...

However when we switch the php extensions to be processed via fastcgi
here is what it happens:

2011-01-18 02:15:26.204 [DEBUG] [HTAccess] Updating configuration file
[/home/support/public_html/.htaccess]
2011-01-18 02:15:26.204 [DEBUG]
[xxx.xxx.xxx.xxx:48382-0#APVH_support.com] [REWRITE] Rewrite engine is
not enabled for context '/'
2011-01-18 02:15:26.204 [DEBUG]
[xxx.xxx.xxx.xxx:48382-0#APVH_support.com] Find handler [1H FCGI PHP52]
for [.php]
2011-01-18 02:15:26.204 [DEBUG]
[xxx.xxx.xxx.xxx:48382-0#APVH_support.com] processContextPath() return 0
2011-01-18 02:15:26.204 [DEBUG]
[xxx.xxx.xxx.xxx:48382-0#APVH_support.com] run fcgi processor.

As you can see above none of the lines are showing "sexec" like behavior
for the php fastcgi processed scripts. Nothing here shows suphp/suexec like behavior which is observed when we running the phps via the lsapi.

We were wondering is this some kind of limitation imposed by the trial
license key we are using, something like a bug in the litespeedhttpd product or just a misconfiguration on our end.

The litespeed web server is configured to parse apache server
configuration file.

Thank you in advance for your help.

vaLentin
 
Last edited by a moderator:

webizen

Well-Known Member
#2
For External Application type, you should choose LSAPI App instead of Fast CGI. There is no issue with trial key. You get full functions in the trial period.
 
#3
For External Application type, you should choose LSAPI App instead of Fast CGI. There is no issue with trial key. You get full functions in the trial period.
But the PHPs we are trying to use are compiled with fastcgi support. They do not have lsapi support build in.

Can't we just use PHP with fast CGI without heaving to build them with lsapi?

As far as I can understand from your reply it seems that PHPs with fast-cgi can not be used with suexec or I am getting it wrong?

Valentin
 

webizen

Well-Known Member
#4
Your understanding is correct: LSWS does not support suEXEC with Fast CGI when httpd.conf is used (like in your case). LSAPI is required.
 
#5
Your understanding is correct: LSWS does not support suEXEC with Fast CGI when httpd.conf is used (like in your case). LSAPI is required.
Thank you very much for the clarification and assistance in this matter. That makes sense.

It would be good if you mention that somewhere at the documentation pages.

Best wishes,

vaLentin
 
Top