chroot virtual host possible with php?

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?

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.

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.

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.

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?

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?

Click to expand...

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?

Click to expand...

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.

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).

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.

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 onLiteSpeed 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.

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.