> With the supplied patch PHP scripts are run under the owners uid *if and > only if* the php binary is copied to every public_html dir that contains > php scripts, symlinking does not seem to work here.
It do not need to be copied. I would not even advise this as it will be problematic due to the disk usage, cache usage and problems with php upgrades. It is sufficient to create 2 line shell script (as ~/public_html/fcgi-bin/php-fcgi-wrapper) #!/bin/sh exec /usr/bin/php5-cgi It is needed becuase of suexec behaviour of running only fcgi scripts being owned by user, and being in proper subdirectory. I already given this wrapper in message #20, as php-fcgi-wrapper. There is nothing unsafe in this file being editable by user, it will be anyway started with rights of user, and nothing beyond what already can be broken in normal php will be broken. (like starting other programs or deleting files). I would not say this breaks suexec. It actually makes suexec work as described in Apache documentation. Also mod_action beheaves in normal way. This is setuped using per directory .htaccess, for exaempl "Action php-fcgi /~baryluk/fcgi-bin/php-fcgi-wrapper". It is also safe to make this file user-editable. It can be owned by somebody else if one really need, or written directly in main configuration file (nested in proper Directory section), or upper in directory hierarchy. It will not break anything. > Also mod_action has to be configured correctly (which I did not figure > out yet for *many* userdirs). I have currently .htaccess in each individual public_html dir of each user which want to have php. The problem you state, is like saying to express: For each php handler with url matchinng "^/~([^/]+)/", use "/~$1/fcgi-bin/php-fcgi-wrapper" as Action. IMHO problem that this is not supported, is problem with mod_actions module, not this patch. > IMHO it is far from production ready. For only few different users it is > rather simple to set up different vhosts with explicit SuexecUserGroup > configs that will give you the same results. I have about 200 users, of which about 50 have PHP enabled. What is even nicer in this (IMHO correct) behaviour after applying patch, is that user can enable/disable php without administrator. Similar one can for example change version of php if he/she whishes. (one can disable this behaviour by disabling htaccess processing, or disabling overriding Actions in per-directory htaccess). For simplicity I just have /etc/skel/public_html/.htaccess with proper Action line, which is comented out, and additional comment what it is, and when it should be comented out. Similary in /etc/skel/public_html/cgi-bin/php5-fcgi-wrapper i have above script (with commented exec and comment that it should uncommented if one wishes PHP). This makes all new users have this files. For old users I copied this files using simple script. BTW. I have disabled php by default as additional security precaution. But one can of course enable it by default, and it will by still good. > Without further action the patch completely breaks PHP script execution > (Error 500) beneath user dirs when suexec is enabled. In my opinion it is not true. It is just a way suexec works. You need to configure it carefully becuase it is very strict. This is also the reason i provided step-by-step detailed configuration (on clean setup with patch). According to the suexec documentation the behaviour of patch is correct. (or maybe you are talking about some other way of exeuting php script? like mod_php or other form of cgi of suphp, etc). Thanks for your comments! From: Stefan Fritsch > I suspect that the patch would break suexec for mod_include's exec > subrequests, but haven't tested it yet. Maybe the note needs to be set > both on the main and the sub request. It is possible. But I do not use includes, and do knot know how exactly they works. I reported this problem with patch on Apache bugzilla, but nobody from developers responds. :( Bug entry is here https://issues.apache.org/bugzilla/show_bug.cgi?id=49439 PS. Exact configuration can be also found on https://issues.apache.org/bugzilla/show_bug.cgi?id=49439#c6 -- Witold Baryluk JID: witold.baryluk // jabster.pl
signature.asc
Description: Digital signature
