Red Hat Bugzilla – Bug 131618
No need for an external httpd-suexec package, if it is always needed
Last modified: 2007-11-30 17:10:48 EST
Description of problem:
Well, I can't see a *real* need/reason for an external httpd-suexec
package - providing 2 small files, if it is always needed by the
Version-Release number of selected component (if applicable):
Actual results / Expected results:
Merge the -suexec package back to the main package and provide/
obsolete the -suexec package there, please.
It allows people to add an httpd-suexec package e.g. with a high epoch
which does not contain /usr/sbin/suexec and so provides a way, albeit
somewhat obscure, of disabling suexec. Does it cause any problems?
Hmmm...it doesn't cause any problem for me, but I think it's a
antilogy to the reason in bug #77972 for splitting it out.
If I have to build an external own package to disable suexec (if I
don't want to break up dependencies), I also simply could do a chattr
+i or something like that (or even rebuild httpd myself without
For me it doesn't make any difference. So maybe you can understand
my thinking which is related with the original problem, causing the
Oh, absolutely no disagreement, it's a dumb hack. Getting a config
option to turn off suexec is a better long-term solution but we need
to do that upstream first, and I'd argue that forcing people to do
chatr +i as Alan suggests is no less a hack. Ideas for better hacks
Closing WONTFIXYETBUTIAGREEREALLY... please re-open if you have a
This is really bad.
A "better hack" would be "no such hack".
You seem to want to make it "easier to disable suEXEC", but the solution (a
dummy httpd-suexec package which wins EVR comparison with all real httpd-suexec
packages and updates) is ugly, needs to be created manually, and can lead to a
situation where "rpm --query httpd-suexec" is successful, but suEXEC would be
I would rather require users, who want to disable suEXEC, to rebuild the httpd
src.rpm --without suexec, and add such a switch to the spec file.
Agreed with comment 4.
But wouldn't disabling suexec be possible to implement using an SELinux boolean?
Then it wouldn't be necessary to decouple httpd and httpd-suexec nor play any
rebuild "--without foo" games.
It's not a matter of making it *easier* to disable suEXEC, but making it
*possible* without doing ugly crap like chatr -i (which triggers RPM errors on
upgrades, presumably), whilst still using the distro-packaged httpd RPM and not
having to rebuild the source RPM with special flags for every update.
But an SELinux boolean sounds like a good solution, indeed. I'll the SELinux guys.
You'll be pleased to hear the SELinux guys liked the idea, so I've folded back
suexec into httpd. Thanks a lot Ville for the excellent suggestion!
Thank you! The suexec sub-package thing was a horribly ugly hack.