Today I whipped out an ebuild for mod_suphp (http://suphp.org/) I attached it and the patch file/.conf needed to build this. For now its only good on Apache v1... It works for me w/ Apache 1.3.31 and php-cgi 5.0.0 (I just bumped up the php-cgi-4.3.8 build for that...should work w/ 4 I imagine) The problem I ran into is that by default, webapp-config installs its webapps as root. This is fundamentally incompatible w/ suphp for a couple of reasons: 1) the whole point is to get things to *not* run as root, and 2) suphp won't run anything owned by root. *shrug* So... To get around it I just created a normal user/group 'wwwapp', and set them to be the default user/group in /etc/vhosts/webapp-config. Then un/re-installed the webapps. I haven't done this on a proper USE=vhosts box yet, FYI.... Is there any particular reason you would need to have webapp-config install everything by default as root? The work-around here is pretty simple, but maybe its something that should be taken into consideration in future webapp-config ebuilds? put the ebuild into /usr/local/portage/net-www/mod_suphp and the patch/conf file into files/ The patch: disables a check that the scripts are in the document root (for user directories), fixes the AddHandler directive, and patches the Makefiles to avoid sandbox errors. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 35781 [details] ebuild for mod_suphp-0.5.2
Created attachment 35782 [details, diff] patch for mod_suphp-0.5.2 disables a check that the scripts are in the document root (for user directories), fixes the AddHandler directive, and patches the Makefiles to avoid sandbox errors.
Created attachment 35783 [details] Default configuration file
webapps are all owned by root as we don't want anybody changing them. we do NOT want the apache user that's running the webapp to have write access to the files. two possible workarounds I see: 1. teach suphp to do user mappings. eg if owner = root, run as nobody 2. change webapp ownership to something else (perhaps webapp-config should provide variables for this). #1 is the only secure option here.
Created attachment 37563 [details] ebuild for suPHP 0.5.2 with Apache 2.0.x I have created an ebuild for mod_suphp with Apache 2.0.x. Perhaps someone wants to merge the two ebuilds, so that we get an ebuild that is working with both versions (1.3.x and 2.0.x).
The usage of fperms in this case does not work, as og-r is implied when using setuid. My suggested modification would be: # See: http://forums.gentoo.org/viewtopic.php?t=208570 for the # answer to another user pkg_postinst() { chmod 4755 /usr/sbin/suphp } Also, RESTRICT="nomirror" should probably be used as the file is not on the Gentoo mirrors yet. Some system needs to be put in place for those who wish to use --with-setid-mode=[force/paranoid] as currently modifying the ebuild is the only way. Two new USE flags could be created but this is not a very elegant solution, plus if both were set one would have to succeed the other. I have attached a proposed new ebuild and a configuration file for Apache2 which is similar in context to those for mod_php, SVN (etc.).
Created attachment 45201 [details] Apache2 configuration file for mod_suphp -DSUPHP can now be used in /etc/conf.d/apache2, however using both -DPHP4 and -DSUPHP should be considered unsupported.
Created attachment 45202 [details] Updated ebuild for suPHP 0.5.2 with Apache 2.0.x Fixes from my previous comment including RESTRICT="nomirror" and corrected file permissions.
Comment on attachment 45201 [details] Apache2 configuration file for mod_suphp ># Please note that using -DSUPHP in conjunction with -DPHP4 will currently ># not work. Whilst it is possible to run both using combinations of ># 'php_admin_flag engine off' and 'suPHP_Engine on', which can be configured ># per-vhost, this is not a supported configuration. > ><IfDefine SUPHP> > <IfModule !mod_suphp.c> > LoadModule suphp_module extramodules/mod_suphp.so > </IfModule> > > <IfModule mod_mime.c> > AddType application/x-httpd-php .php .php4 .php3 .phtml > AddType application/x-httpd-php-source .phps > </IfModule> > > suPHP_Engine on ></IfDefine>
Created attachment 55617 [details] mod_suphp ebuild this ebuild is updated for the new apache locations / eclass. I don't have apache 1.3 installed so this is apache2 only!
Created attachment 55618 [details] files/mod_suphp.conf this is the default configuration file (files/mod_suphp.conf) I forgot to add the headers (from skel.ebuild) for the submitted ebuild. Sorry
forgot to say, that I have not yet tested them (they compile and install correctly). I just wanted to avoid, that somebody else works on the same ebuild. Need some sleep before actually testing them...(4am)
Created attachment 55709 [details] mod_suphp-0.5.2.ebuild ok, the last ebuild did not work. used ./configure instead of econf. This ebuild has the correct header and minor fixes. I tested mod_suphp with 2 small php scripts and it worked. I did _not_ make extensive tests.
I finally had the time to implement a "minUser" in suphp. It is now possible to specify a user in the apache config-files. This user is used, whenever the uid is < --with-min-uid (same for groups). This new ebuild, diff-file and config-file take this into account. Still only for apache2, but suphp and apache1 wouldn't work with webapp-config anyway. I sent the diff to the suphp-author. With some luck we will have a new version soon. Personally I think it's time to accept this ebuild.
Created attachment 58908 [details] the config-file for mod_suphp (will be placed into /etc/apache2/modules.d) added 2 lines: index handling: index.php index.phtml index.php5 and #suPHP_MinUser suphp suphp the example entry for the new feature.
Created attachment 58910 [details] the diff to the standard 0.5.2 suphp files this tar-ball also modifies configure... and not only the code. should also be placed into the files directory.
Created attachment 58911 [details] the new mod_suphp which is suitable for webapp-config
> I finally had the time to implement a "minUser" in suphp. I'm not sure this should really be done. Minimum and maximum users can be set at compile time. You don't want it to be able to be configured at any other time, the checks for minimum UID are in place so that scripts owned to root (and other lower numbered daemon accounts) return 500 errors, not content. If the owner of a file is root, it should not be run through PHP and returned to the user, period. It should not be mapped to another user because there is no guarantee that the user will even be able to read the script file, hence the addition of complexity to SuPHP that isn't necessary. It will be interesting to see what Sebastian says about the patch but, personally, I do not like it.
But the whole point is to be able to use root-owned files. Otherwise suphp can't be used with webapp-config. I did not change the min-max test. It's still configured at compile time. But if and only if you specify a suPHP_MinUser you may use webapp-config installed programs. To add a mapping user is not only my idea, but was mentioned in comment #4 as well. I don't see another way to install system-wide programs and use suphp as well. Even if you changed the owner of web-applications to be something > then min-user, it could IMO open security holes, because most php-developers don't expect there programs to be "self-changeable". What I mean, they propably expect their programs to run under a different user (normally apache) than what they are installed.
Created attachment 59157 [details] 70_mod_suphp.conf After some thinking I realized that the easiest (and maybe only) way to support webapp-config is to use the user apache:apache. Here is the modified config file to use apache:apache as example (and not suphp:suphp) (this file goes into the files directory)
Created attachment 59158 [details] mod_suphp-0.5.2.ebuild removes the suggestion to add the user suphp:suphp
0.6.0 is out
Created attachment 61567 [details] mod_suphp-0.6.0.ebuild This is my modified version of the old ebuild to compile the new one. minUID-patch is no longer needed as it's included upstream (am I right?). But there's a compile issue confirmed by another gentoo user on the suphp mailing list. To work around this, we have to edit src/apache2/Makefile.in. The attached ebuild does this edit and compiles (afaics) mod_suphp cleanly. But I have trouble running it, apache just serves all files as sourcecode (mime type application/x-httpd-php) instead of passing it to the interpreter. Don't know if this is a bug or a misconfiguration but just replacing a working 0.5.2 installation with this 0.6.0 version acts as described. Anyone an idea?
Created attachment 63014 [details] mod_suphp-0.6.0-r1.ebuild Modified ebuild which also installs /etc/suphp.conf and allows to modify some options at build-time through environment variables.
Created attachment 63015 [details] files/70_mod_suphp.conf
Created attachment 63016 [details] files/suphp.conf
(In reply to comment #23) > The attached ebuild does this edit and compiles (afaics) mod_suphp cleanly. > But I have trouble running it, apache just serves all files as sourcecode (mime > type application/x-httpd-php) instead of passing it to the interpreter. Don't > know if this is a bug or a misconfiguration but just replacing a working 0.5.2 > installation with this 0.6.0 version acts as described. > Anyone an idea? Take a look at my modified ebuild. I think you forgot to set SuPHP_AddHandler and the /etc/suphp.conf file.
Jochen, This latest e-build works great "out-of-the-box." Thanks for all the work you've put into it. Also, FYI, it is working well for me on several Opteron systems, so I recommend adding the "~amd64" keyword. ;-)
in cvs finally
the default suphp.conf is for use with stuarts php overlay (where you can install php4 and php5 at the same time), so i added some more handlers to be able to serve .php5 and .php4 different...
