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
Problem is that after making this change, on an upgrade, suexec will silently
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
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
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.