Bug 77972 - suexec package seperation
suexec package seperation
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-15 19:51 EST by Emmanuel Galanos
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-28 15:35:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Emmanuel Galanos 2002-11-15 19:51:23 EST
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-03 22:25:02 EDT
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-03 22:29:07 EDT
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 04:38:45 EDT
Problem is that after making this change, on an upgrade, suexec will silently
disappear.
Comment 4 H. Peter Anvin 2004-05-23 16:49:08 EDT
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 Emmanuel Galanos 2004-05-23 17:20:49 EDT
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 11:15:25 EDT
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 15:35:32 EDT
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 05:23:58 EDT
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.