Bug 77972

Summary:	suexec package seperation
Product:	[Fedora] Fedora	Reporter:	e
Component:	httpd	Assignee:	Joe Orton <jorton>
Status:	CLOSED RAWHIDE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1	CC:	chris.ricker
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-06-28 19:35:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description e 2002-11-16 00:51:23 UTC

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)

Comment 1 H. Peter Anvin 2003-07-04 02:25:02 UTC

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.

Comment 2 H. Peter Anvin 2003-07-04 02:29:07 UTC

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.

Comment 3 Joe Orton 2003-07-04 08:38:45 UTC

Problem is that after making this change, on an upgrade, suexec will silently
disappear.

Comment 4 H. Peter Anvin 2004-05-23 20:49:08 UTC

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.

Comment 5 e 2004-05-23 21:20:49 UTC

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.

Comment 6 Alan Cox 2004-06-21 15:15:25 UTC

Agreed in part. Running a custom suexec for the computer society we
ended up simply doing chattr +i  on it.

Comment 7 Joe Orton 2004-06-28 19:35:32 UTC

OK, fixed for FC3 by splitting out /usr/sbin/suexec into an
httpd-suexec package.  Thanks for the reports.

Comment 8 Joe Orton 2004-08-18 09:23:58 UTC

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.