llongi's blog

#gentoo-db has just opened its (virtual) doors (or windows or terminals, depends on what IRC client you use).

The new channel is intented to provide a platform for discussions, concerning both support and development, centering on Gentoo and databases.
At the moment Gentoo MySQL and PostgreSQL people hang out there, but it's my hope to see other developers and/or teams that maintain database-related packages for Gentoo (Firebird, Oracle, SQLite, BerkeleyDB, ...) join too, as well as users with experience in SQL and database administration, or just people interested in databases and their uses.

For all those who wondered, PHP in Gentoo is definitely not dead. ;)

Just put new revisions in the tree (dev-lang/php-4.4.2-r6 and dev-lang/php-5.1.4-r4), that fix various bugs and security issues. On that note, a big thanks to Stefan Esser from Hardened-PHP.net for all his patches and work on securing PHP (and of course the Hardened-PHP patch itself)!
The new PHP revisions also introduce a better separation between eclasses and ebuilds, making their management and the addition of new features easier.

One of these new additions for now is the "concurrentmodphp" USE flag.
It enables building mod_php4 and mod_php5 in a way that both can be loaded at the same time into the same Apache2 instance, each mod_php then has its own mime-types (application/x-httpd-php4{-source} for PHP4 and application/x-httpd-php5{-source} for PHP5) and configuration modifiers (php4_admin_value/php4_admin_flag for PHP4 and php5_admin_value/php5_admin_flag for PHP5 and so on). This feature is highly experimental, I could confirm it working on my x86 system and partially on an x86_64 system, but I'd very much like for users to try it out on systems where breakage is allowed (developement systems or test systems) and report back the results to me, thanks!
To try it, do the following:

emerge --sync
echo dev-lang/php >> /etc/portage/package.keywords
USE="apache2 concurrentmodphp" emerge =php-4* =php-5*

then don't forget to "etc-update" and re-emerge all of your installed PHP modules/extensions (such as dev-php4/pecl-zip). Also all this does not work with the "java-internal" (PHP4) and "sharedext" (PHP4/5) USE flags enabled, so be sure to disable them when you emerge php.

A few days ago I added support for MPM-itk ("mpm-itk" USE flag) to our Apache 2.0 packages. MPM-itk is a user-switching MPM, that is, it switches to an assigned user when processing the requests, instead of processing everything as user apache (MPM-perchild, metux-MPM and MPM-peruser are other examples of this).
In its original form it accomplishes this by doing the following:

• apache process as root, interpret the request
• fork() new process and switch (setuid(unprivuid) / setgid(unprivgid)) to unprivileged user for it, process the request
• kill of the setuid/setgid process, with the next request it will redo the process

Now, this is foolproof, but provokes an immense performance hit, especially on static pages. Benchmarks done with ab2 showed that a normal Apache2 (MPM-prefork) can process about 240 PHP req/sec and 4000 HTML req/seq, while the MPM-itk patched Apache 2.0 managed about 110 PHP req/sec and 240 HTML req/sec, so you see, the peformance hit is enormous, and it's obiously due to the overhead of always having to fork() a new Apache process and then kill it off, for every request!
I managed to successfully change the way the MPM works, and thus managed to bring its speed to normal Apache levels, by changing the "worfklow" like this:

• apache process as root, interpret the request
• switch (setresuid(unprivuid, unprivuid, 0) / setresgid(unprivgid, unprivgid, 0)) to unprivileged user, process the request
• switch back to root (setresuid(0, 0, 0) / setresgid(0, 0, 0)), with the next request it will redo the process

Now this solves the performance problems, as it doesn't anymore do the extra fork(), and fully reuses the process with the next request, but it introduces a new problem: a gaping security hole. :(
Since the processed request cannot be trusted, everything in there can simply setuid/setgid to root and do operations as root! A simple call to, for example, the posix_setuid/posix_setgid functions of the PHP POSIX extensio are enough to switch the user back to root and let the rest of the PHP script just work as root... This is totally unacceptable for security. So, now my call for help: has anyone got any idea how it's possible to realize this in a secure manner??? I can't think of any way to securely switch the process from root to unpriv user and back to root, without giving the untrusted code executed in the request processing phase the same ability (that is, to switch back to root).
Ideas and comments are very appreciated. ;)