@Cassidy said:
They probably don't. Was simply bragging that I'm not a hosting company and yet I have easier (and apparently more secure) deployment measures than they seem to have.
Fair enough. Altogether too many “hosting companies” buy a WHM/cPanel license and let it do all the work for them without understanding what that work is.
@Cassidy said:
suPHP also provides each vhost with its own indivudal php.ini config settings. Not sure if ruid2 does that.
Not so much. As opposed to specializing in running one thing (CGIs, mod_php, etc.) as a different user, it lets the entire Apache worker process assume the permissions of a user when serving the request, so everything relating to that request (SSIs, mod_*, CGI, etc.) runs as that user and with that user's permissions.
@Cassidy said:
However, that module looks interesting. There any further documentation other than "mod_ruid2 is a suexec module"...?
How succinctly you have hit upon the project's greatest fault. The extent of its documentation is its readme; however, it's fairly intuitive to configure once you know what the available directives are.
The big flaw I've noticed is that because ownership of worker processes is given to a non-www-user
user, Apache gets really confused when it comes to counting up and maintaining the MinSpareThreads
/MaxSpareThreads
limits. YMMV. The other issue, which I'm not terribly concerned about but some might be, is that in order to change the ownership of worker processes, the master Apache process must run as root
. Doesn't bother me too much as exploitation of that fact would require the presence of a fairly gaping hole very, very deep in Apache's guts, but it's something to be aware of.