Bug 350831 - reduce suexec minimum gid
reduce suexec minimum gid
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-24 13:22 EDT by Kenneth Porter
Modified: 2009-10-13 10:15 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-13 10:15:59 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 Kenneth Porter 2007-10-24 13:22:55 EDT
When installing a daemon package that can use suexec to avoid a separate httpd
instance (in my case, backuppc), one must set the UID of the package user to
greater than 500 to use suexec with its management CGI. This conflicts with the
band of UID's reserved for end-user assignment. Ideally suexec's AP_UID_MIN
should be somewhat below 500, to allow a band of UIDs for use by system services
needing a web management interface.

See also bug 107083 and bug 127667, where the minimum GID was reduced from 500
to 100.
Comment 1 Joe Orton 2007-11-01 07:36:25 EDT
It is rather than point of the minimum GID/UID to *avoid* being able to use
suexec with "system" users.  The minimum GID was lowered only because of the
issue with the existing gid=100 users group (essentially, a migration issue).
Comment 2 Kenneth Porter 2007-11-08 13:12:07 EST
Would it be preferable, then, to run multiple Apache instances as different
users? If so, should I enter an RFE against httpd to provide initscripts that
can launch multiple instances?
Comment 3 Joe Orton 2009-10-13 10:15:59 EDT
Sorry that I never responded to that question.  Really the only "preferable" option here is to ensure both your uids and gids are >= 500.

Marking closed since the minimum uid is set deliberately for security purposes; apologies that this is unsatisfying for some deployments.

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