Bug 77972 - suexec package seperation
Summary: suexec package seperation
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-16 00:51 UTC by e
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-06-28 19:35:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.



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