Bug 621133

Summary: Misleading comment in httpd.conf
Product: [Fedora] Fedora Reporter: Dave McNeill <dave.mcneill>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 13CC: jorton, pahan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-04 13:09:58 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 Dave McNeill 2010-08-04 11:05:51 UTC 
The default httpd.conf installed with the Red Hat httpd RPM contains a <Directory /> clause as follows:

# First, we configure the "default" to be a very restrictive set of 
# features.  
#
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

This is clearly a modified version of the equivalent clause in the vanilla 2.2.15 sources:

# First, we configure the "default" to be a very restrictive set of 
# features.  
#
<Directory />
    Options FollowSymLinks
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

The difference is that the directives which implement the restrictive set of features have been removed from the RPM version. Can I suggest that the comment in the RPM version is changed to something like this:

# First, we configure the "default" to be a very liberal set of features.
# You should consider changing these before putting your HTTP server into
# production.
Comment 1 Joe Orton 2010-08-04 13:09:58 UTC 
You're conflating "features" and "access control".  This section of the config was inherited from upstream verbatim, though it's since been modified upstream.  It disables "features" - Options and AllowOverride, restricting such config "features" is not inconsistent with an absence of access control restrictions.

A broader review of our httpd.conf vs upstream would certainly be welcome, considering impact of changes like this on any shipped webapps (e.g. doing as you suggest would break people using /srv which is not really desirable).  I'd rather have this discussion on the devel@ list rather than in bugzilla.