On Fri, Sep 07, 2007 at 06:21:25PM +0200, Roland Tapken wrote: > A few days ago, i wondered why apache ignores my afford to define a > per-directory auto_prepend-file via "php_flag". Until is recognized that this > won't work because i'm using suphp. Of coure i knew the reason, but > sometimes... you know what i mean, don't you?
I think you mean that a few days ago, you were confused as to why Apache kept ignoring your php_flag options -- but then you realised it was because you had moved away from using the native module-based PHP interpreter (mod_php5) and moved to mod_suphp. > Hm what about a "suphp_flag" which might be appended with "-d VAR=VALUE" to > php-cgi? Of course there should be some way to restrict which values might be > personalized, for example a list of allowed/disallowed directives in > suphp.ini. Passing command-line arguments introduces a large number of potential security holes. Of course it depends on whether or not a shell is spawned prior to php-cgi being executed (that is to say, execl(3) vs. system(3)), since in the latter case, you have to deal with quote escaping, backtick removal, quoting interpolation, and a bunch of other painful issues. That said, limiting what options are supported would probably the best way to ensure above security issues don't come to light. Your idea is a good one, I think. :-) Sadly, and I mean this in a very respectful way, suphp is a hack for something Apache should really be doing itself. Apache really needs a way to execute entrance code in modules as a specific user/group, and not via a sub-process. The configuration would look like this: LoadModule mod_module_security libexec/apache22/module_security.so LoadModule mod_php5 libexec/apache22/php5.so User www Group www AddType application/x-httpd-php .php <VirtualHost www.whatever.com> ServerName www.whatever.com ModuleSecurity mod_php5 username groupname </VirtualHost> The reason this can't be done at the present time, using the above example, is because Apache switches to user www group www right after opening logfiles (as root, which is a separate security concern :) . Thus all forked httpd processes or httpd threads are run as www/www, so there's no way to setuid() to username or setgid() to groupname. Something like this would require patching the actual Apache source to "retain" root privileges for some things, or possibly spawning a child process that handled user/group priviledge escalation itself. I *have* seen some modules which switch user/group credentials prior to any file being accessed via Apache, but they impose a gigantic performance hit by performing all of the initial access in the parent Apache process (which runs as root), and re-spawning a httpd child child *per request*. I guess the "easiest" way to achieve all of this is to use something like jails (on the BSDs), but sometimes those are tedious to deal with/maintain. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ suPHP mailing list [email protected] http://lists.marsching.biz/mailman/listinfo/suphp
