chroot virtual host possible with php?

[sofatime]

I have just installed lsws and have two questions:

1) I have created a virtual host and have set "CGI Chroot Mode" to "Virtual Host Root". This does not have any effect on PHP-requests, I can still read files like /etc/passwd (not using open_basedir). Is this correct?

2) I have deleted the global PHP Handler and External App and created one in the virtual host using "CGI Set UID Mode DocRoot UID". This works great. When I open phpinfo.php I cannot see APC anymore (which showed up ok in phpinfo.php with the global php configuration). Why is that?

Thanks!
Daniel

 

[mistwang]

Answers to your questions:
1. It is possible but not recommended, as you need to build the jail environment manually for each every chroot vhost. that is not a easy job. Instead, we recommend chroot at server level along with suEXEC, our Enterprise edition has the best chroot support which can build the initial jail environment automatically.

2. Probably the setUID PHP process does not use the default php.ini, just check which php configuration file is used in phpinfo()'s output. Other than that, you should check file permissions. lsws/logs/stderr.log may log something useful.

 

[Arkadius]

sofa are you using more than one site ?

if so please post your php handler.
i am testing since 2 days without any progress.

thank you

 

[mistwang]

Arkadius,

Are you talking about PHP suEXEC for multiple vhosts?
You need to set http://www.litespeedtech.com/docs/config/vhostlist/#vhCGISetUidMode to "Docroot UID", then define lsphp external app and script handler for that vhost, cannot share the global PHP handler.

 

[Arkadius]

could you please post a direct example for the lsphp external app ?

i have around 120 templates (each customer is created as a template) each with their vhosts listed inside of the template.

i would like to have every template run its own php with dedicated user ids.
but that isnt really working at the moment.

i cant see any way how i would create the desired lsphp that will run like you posted.

 

[mistwang]

120 templates! You kidding! If each template has only one vhost, you should just create the vhost directly.

For a template, you should set template->security tab -> "CGI Resource Control" -> "CGI Set UID Mode".

When you define an external app in a template, you should use some thing like "$VH_NAME_lsphp" as the app name.

 

[Arkadius]

well most of the templates have more than 2 vhosts, some have up to 80
i dont want to split them up into vhosts by domain, i rather have them as template so if i change someting the customer account is affected and not just a single domain.

my security tab looks like this for the default template that i spread around :

question now is,

what settings do i need in my lsphp application in order to have it run under the users id. is it possible for you to post a screenshot of your configuration ? or pass the xml file? and how would i tell the vhost to use that external application to process .php files ? i have only found the global solution.

 

[mistwang]

CGI Chroot Mode should be "Same as Server" unless you want to build chroot jail environment for each every vhost. too much trouble.

To let a vhost use this own lsphp, you should add a PHP LSAPI application with similar configuration as the global one. make sure the name is like "$VH_NAME_lsphp", then under "General" tab -> "Script Handler Definition", add a script handler for ".php" using $VH_NAME_lsphp as the handler. This will override the global php handler configuraiton.

 

[sofatime]

Thank you. I have now installed lsws with chroot and I have now a lsphp process per virtual host with the user of that virtual host. So it looks very good so far.
I had one more problem: You mentioned in another post, that one should have a user and a group per virtual host and use permissions 660 so no customer can read data of another customer. Additionally one should add the lsws user to every customer group so lsws can still read files. That is a good solution but on Solaris you can put a user only in 16 groups (or 32 if you change that limit). Therefore I didn't add the lsws user to every group but used ACLs to add the lsws user to the directories. Worked too. Anybody got a better solution?

About APC and phpinfo: I am a bit confused which php.ini that could be. There is no other php.ini. phpinfo says "Configuration File (php.ini) Path: ../conf". But is this meant from the virtual host root?

Daniel

 

[mistwang]

but on Solaris you can put a user only in 16 groups (or 32 if you change that limit). Therefore I didn't add the lsws user to every group but used ACLs to add the lsws user to the directories. Worked too. Anybody got a better solution?

That can be a problem, I am not sure Linux has this limit or not, will investigate. Using ACL is a good solution too, probably even better for system supports that.

About APC and phpinfo: I am a bit confused which php.ini that could be. There is no other php.ini. phpinfo says "Configuration File (php.ini) Path: ../conf". But is this meant from the virtual host root?

If phpinfo shows only "../conf" then PHP cannot found the php.ini in the give path, that path should be a relative path to the lsphp executable, if you make a copy of lsphp to every vhost, then you should copy php.ini as well. I would rather use one global lsphp binary, suEXEC does not affected unless you want to use different php.ini for different user.

 

[sofatime]

about group limit: I think Linux kernel 2.6 supports 65536 group memberships, older also only 32 (NGROUPS_MAX).

about php.ini: Sorry, I still don't get it: I didn't copy lsphp nor php.ini. lsphp is in chroot/opt/lsws/fcgi-bin and php.ini in chroot/opt/lsws/conf. In the virtual host configuration I used:
command: $SERVER_ROOT/fcgi-bin/lsphp
address: uds://tmp/lshttpd/$VH_NAME_php.sock
(btw: shouldn't I see the sock file in /tmp/lshttpd? there is none)

There is one other strange thing: In the global config I deleted the script handler (for testing), then re-created it, but php is not working in the global server anymore (php-files just get downloaded).

Any idea?
Thanks
Daniel

 

[mistwang]

OK, I see, it is more like that setuid PHP process do not have read permission on php.ini.

For the other problem, clearing your browser cache may help.

 

[sofatime]

You were absolutely right about both things. Working perfectly now!

Thank you
Daniel

 

[Arkadius]

I am still fighting with my Server to get it all up and working :

Whenever I enable the Listener I get the following Error ->

http://www.dorijan.de/lsws/error.jpg

i created the following application within lsws

then went into Security Tab and set these Options ->

then restarted the websever and boom 503.
nothing inside the logs except worker process started/stopped. no errors no nothing.

any ideas ?

and last but not least i selected General and set ->

 

[mistwang]

I don't think your chroot environment has been configured properly, it is not some thing would work by just setting the chroot path to an arbitrary path without substantial work involved. You need to learn more about setting up a chroot environment manually if you want to chroot at vhost level.

Our Enterprise edition can build a chroot environment easily at the server level. And it will give enough protection for the server along with CGI SuEXEC. Virtual host level chroot is not recommended unless you are really know what you are doing.

 

[Arkadius]

Hello mistwang,

I do not really need a full chroot on my server since no user is ever going to be able to login via ssh and if all scripts run under each users personal id there is no access to anything besides the dir they are supposed to use and the non execute mounted /tmp partition.
i never had to create full chroot environments on zeus or apache in order to use suexec.

while following the guide listed on
LiteSpeed Wiki
there is nothing about chroot written there at all so why would I need chroot suddenly ?

i was asking where to look for hints regarding the 503 error I am getting after setting up a 2nd lsphp application inside the vhost template which is an exact copy of the standard lsphp application. the logfiles dont show anything at all.

 

[xing]

suexec is just execution of external app under a different UID from that of the server. If you just need suexec, disable chroot, and set your "CGI Chroot Mode" to "Same as Server". Right now you have it set to vhost level and if you don't have a real chroot env in your vhost path, it will not work.

Chroot is a whole different matter from suexec and right based on your screen capture, you have both enabled.

As far as the lacking of log for your 503 errors, please enable debug logging level and set it to maxium. Recreate the 503 error and check log.

Will check to see if "$VH_NAME" variable replacement is actually supported in the Name and Address fields you have used.

 

[Arkadius]

i have now set CGI Chroot Mode as you requested.

this is the entry from the error.log set to DEBUG

2006-07-20 10:10:33.509 [DEBUG] [85.14.217.59:54689-0#dorijan.org] New request:
        Method=[GET], URI=[/uid.php5],
        QueryString=[]
        Content Length=0
2006-07-20 10:10:33.509 [DEBUG] [85.14.217.59:54689-0#dorijan.org] Find context with URI: [/], location: [/home/d00001/websites/dorijan.org/]
2006-07-20 10:10:33.510 [DEBUG] [85.14.217.59:54689-0#dorijan.org] Find handler [dorijan.org_lsphp] for [.php5]
2006-07-20 10:10:33.510 [DEBUG] [85.14.217.59:54689-0#dorijan.org] processContextPath() return 0
2006-07-20 10:10:33.510 [DEBUG] [85.14.217.59:54689-0#dorijan.org] run lsapi processor.
2006-07-20 10:10:33.510 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] reconnect()
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onWrite()
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] request header is done
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::continueRead()
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Request body done!
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::suspendWrite()
2006-07-20 10:10:33.511 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] processNewReq() return 0.
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onRead()
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] LsapiConn::doRead()
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] process packet header -1 bytes
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] connection to [uds://tmp/lshttpd/dorijan.org_lsphp.sock] on request #1, error: Connection reset by peer!
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] close()
2006-07-20 10:10:33.512 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] reconnect()
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onWrite()
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] request header is done
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::continueRead()
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Request body done!
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::suspendWrite()
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] close()
2006-07-20 10:10:33.513 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] reconnect()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onWrite()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] request header is done
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::continueRead()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Request body done!
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::suspendWrite()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onError()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onRead()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] LsapiConn::doRead()
2006-07-20 10:10:33.514 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] process packet header 0 bytes
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onRead()
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] LsapiConn::doRead()
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] process packet header -1 bytes
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] connection to [uds://tmp/lshttpd/dorijan.org_lsphp.sock] on request #1, error: Connection reset by peer!
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] close()
2006-07-20 10:10:33.516 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] reconnect()
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::onWrite()
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] request header is done
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::continueRead()
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Request body done!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] ExtConn::suspendWrite()
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] [ExtConn] close()
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpIOLink::continueWrite()...
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] write resumed!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpIOLink::handleEvents() events=4!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpIOLink::suspendWrite()...
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpConnection::sendHttpError(),code=503 Service Unavailable
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpConnection::flush()!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Written to client: 637
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpConnection::nextRequest()!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpExtConnector::cleanUp() ...
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] abort request...
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] release ExtProcessor!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Non-KeepAlive, CLOSING!
2006-07-20 10:10:33.517 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Shutting down out-bound socket ...
2006-07-20 10:10:33.518 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] HttpIOLink::handleEvents() events=17!
2006-07-20 10:10:33.518 [DEBUG] [85.14.217.59:54689-0#dorijan.org:lsapi] Close socket ...

 

[mistwang]

The problem is in your lsphp configuration, "Memory soft limit (Bytes)" and "memory hard limit (Bytes)" is too low, should set to "100M" and "150M", by appending a "M". Should work.

 

[Arkadius]

thank you very much, it works perfekt now.