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 main package... Version-Release number of selected component (if applicable): httpd-2.0.50-5 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 suexec). For me it doesn't make any difference. So maybe you can understand my thinking which is related with the original problem, causing the breakout.
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 welcome :) Closing WONTFIXYETBUTIAGREEREALLY... please re-open if you have a better hack.
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 missing nevertheless. 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.