httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: typo in security-tips.html (fwd)
Date Wed, 23 Apr 1997 18:20:37 GMT


---------- Forwarded message ----------
Date: Wed, 23 Apr 1997 14:37:46 +0900
From: "Stephen J. Turnbull" <>
To: Rob Hartill <>
Subject: Re: typo in security-tips.html 

Dear Rob:

I've done the installation and played around a bit with the
access.conf file.  Here's my access.conf file with the irrelevant
comments for new users deleted and comments on what my understanding
of the functionality is along with what I've tested.

There are a couple of points that I think should be added to the
documentation, as noted below.

It just occured to me that probably I should be going through the bug
tracking system with these comments, but it's just too painful to
access the server internationally (I just now failed to access because
of a timeout).

Thanks for your attention.

Best regards,

# Some paranoia, as recommended in "security-tips.html" in the section 
# explaining what could happen with "cd / ; ln -s / public_html".

# This first <Directory> directive denies access everywhere it is not
# specifically permitted.  It shuts off all server options (I suppose
# this is unnecessary given the "deny"), and shuts off .htaccess
# overrides.
# I think it works because I was unable to access my ScriptAliased
# /WWW/cgi-bin programs until I explicitly turned on ExecCGI for that
# directory, nor my Aliased /WWW/icons directory until access was allowed.
<Directory />
AllowOverride None 
Options None
Order deny,allow
Deny from all

# Allow accesses to users public_html directories, including
# server-side includes, but no other options.
# Untested
<Directory /home/*/public_html>
Order deny,allow
Allow from all
Options IncludesNOEXEC

# Permit accesses in DocumentRoot and subdirectories
# I believe that this works, as it has been tested for many but not
# all subdirectories (my file system is pretty complicated).   I
# haven't tested that CGIs or shtmls cannot exec programs here, but I
# assume that works as documented.
<Directory /WWW/htdocs>
Options Indexes FollowSymLinks IncludesNOEXEC
AllowOverride None
order allow,deny
allow from all

# Presumably the next two <Directory> sections are needed in this
# config but not in the default because of the "<Directory />"
# section.
# ScriptAliased CGI directory
# The "Options ExecCGI" directive is _not_ in the sample access.conf
# and not mentioned in the section on how to plug the potential hole
# via "cd /; ln -s / public_html" ("Protect server files by default")
# It is necessary; I could not execute CGIs there until I added that
# directive.  The ScriptAlias directive in srm.conf is _not_ sufficient.
<Directory /WWW/cgi-bin>
order allow,deny
allow from all
AllowOverride None
Options ExecCGI

# This is necessary; the Alias directive in srm.conf is insufficient.
<Directory /WWW/icons>
order allow,deny
allow from all
AllowOverride None
Options None

# This does _not_ work as I expected (but I believe the documentation
# is correct), and it's probably completely unnecessary.  There is a
# symbolic link
#	       /WWW/htdocs/public-ftp -> /WWW/home/pub
# (this organization is a legacy of my prior FTP server, and I haven't 
# fixed it).
# There is no index.html in /WWW/home/pub.  By the default access
# rule, using the symbolic link I get a FancyIndex.  This was a
# surprise (but shouldn't have been).
# Note: use of the URL "file:/WWW/home/pub/" in Netscape works, and
# gives a FancyIndex-like output.  But this is a direct access by
# Netscape, not mediated by httpd.  This is probably obvious to you,
# and I'm embarrassed to admit it.  But maybe it should be
# documented; other naive Web admins may be fooled the same way.  I
# can't see how to access this directory via httpd without the symlink.
<Directory /WWW/home/pub>
order allow,deny
allow from all
AllowOverride None
Options None

# Allow server status reports, with the URL of http://servername/server-status
# Change the "" to match your domain to enable.
# That is a strange notation, but it seems to work.
# It may be a configuration problem in my networking (in /etc/hosts,
# eg), but the "allow from localhost" seems to be necessary to access
# server status via the url "http://localhost/server-status", even when 
# I change to "allow from".
<Location /server-status>
SetHandler server-status

order deny,allow
deny from all
allow from
allow from localhost

View raw message