Bug 131618 - No need for an external httpd-suexec package, if it is always needed
Summary: No need for an external httpd-suexec package, if it is always needed
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-02 18:04 UTC by Robert Scheck
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 19:58:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Robert Scheck 2004-09-02 18:04:52 UTC
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.

Comment 1 Joe Orton 2004-09-02 18:12:09 UTC
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?

Comment 2 Robert Scheck 2004-09-02 19:36:41 UTC
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.

Comment 3 Joe Orton 2004-09-02 20:54:03 UTC
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.

Comment 4 Michael Schwendt 2005-04-18 12:36:07 UTC
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.

Comment 5 Ville Skyttä 2005-04-18 15:29:31 UTC
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.

Comment 6 Joe Orton 2005-04-18 15:34:31 UTC
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.

Comment 7 Joe Orton 2005-04-26 09:02:17 UTC
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!

Comment 8 Warren Togami 2005-04-26 19:57:47 UTC
Thank you!  The suexec sub-package thing was a horribly ugly hack.


Note You need to log in before you can comment on or make changes to this bug.