It would be useful if suexec was seperated out into a package httpd-suexec. This would provide: o Security: hosts that do not need it have 1 less SETUID program lying around. o Flexibility: Easier customisation of suexec as there would only be 1 package to replace (example having cgi-bin inside users home dir next to public_html)
I would like to recommend this bug as well. Unfortunately, Apache has no directive to disable suexec, and if /usr/sbin/suexec exists, it will use it. Therefore it seems necessary to separate it out into a separate package, since those of us who find that the suexec security model is worse than the default security model have to rm -f /usr/sbin/suexec every time the apache RPM is upgraded. Please, pretty please, separate it out into a httpd-suexec package.
This really should be a "security" bug, because the current situation is that an upgrade can cause a silent change to the security model that the admin may not expect.
Problem is that after making this change, on an upgrade, suexec will silently disappear.
Well, as it is, in a non-suexec environment, you have to remove the suexec binary AFTER EVERY APACHE UPGRADE. This is beyond infuriating; it is in fact a catastrophic maintainability bug. I have now had at least four servers with downtime because of this bug at various points in time. suexec is and must be an option.
A maintainability workaround I use for our servers (where I have a custom version of suexec), is my own package bla-suexec which contains in the spec file: %triggerin -- apache < 2.0, httpd # Copy custom suexec on top of package supplied. ... You could create an empty package which just contains an rm inside the trigger.
Agreed in part. Running a custom suexec for the computer society we ended up simply doing chattr +i on it.
OK, fixed for FC3 by splitting out /usr/sbin/suexec into an httpd-suexec package. Thanks for the reports.
We're going to have to add back "httpd requires httpd-suexec"; to have a packaged system without suexec you'll have to install a dummy httpd-suexec package with a high Epoch which doesn't contain /usr/sbin/suexec. Otherwise this change itself causes a silent change to the security model on upgrades, when /usr/sbin/suexec gets removed: if CGI scripts in userdir directories are enabled they will suddenly start running as the user rather than as 'apache'. The cause of this bug really is that there is no directive to globally disable/enable suexec, am discussing a better long-term solution to this with upstream.