Date: Mon, 3 Feb 1997 12:13:53 +0000 (GMT)
From: Rob Hartill <robh@imdb.com>
To: Apache Group <new-httpd@hyperreal.com>
Subject: Apache 1.2b6 and FollowSymLinks (fwd)
Message-ID: <Pine.BSF.3.91.970203121343.2273B-100000@localhost.imdb.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com


not acked

---------- Forwarded message ----------
Date: Mon, 3 Feb 1997 11:37:19 +0000 (GMT)
From: WWW server manager <webadm@info.cam.ac.uk>
To: apache-bugs@apache.org
Subject: Apache 1.2b6 and FollowSymLinks

This is actually a repeat, in effect, of a problem I reported last August 
against Apache 1.1.1. I didn't get any response to that, so I don't know if 
it's the code or the documentation that's wrong, but one or the other has to 
be (assuming that the documentation should mention all significant effects, 
rather than mentioning one an omitting another equally important one!).

The documentation for "Options FollowSymLinks" says just "The server will 
follow symbolic links in this directory.". [Quoted from 
http://sunsite.doc.ic.ac.uk/packages/apache/docs/mod/core.html#options ]

The reality is that absence of FollowSymLinks prevents a symlink being followed
*to* such a directory, *from* one in which symlinks are supposedly enabled.
Or that is how it appears with both 1.1.1 an 1.2b6; removing the restriction on 
the target directory (no chance to config for source directory) allows the link
to be followed. [Tests with a .htaccess file in a directory which is directly
within the data directory hierarchy, not accessed via a symlink, confirms it
does also block "outbound" symlinks, if you can get into the directory in the 
first place.]

What is the intended behaviour? 

In my case, I've only ever wanted to disable following symlinks in directories
which were outside the main directory hierarchy, accessed via a symlink from 
there (because anything within the main hierarchy can be updated only by me 
and trusted colleagues, whereas some of the other directories are not trusted). 
Thus, to me the documented behaviour seems preferable - if we can take the 
absence of any mention of the option blocking access *to* the directory as
meaning that wasn't an intended effect!

This does raise the question of compatibility if the code was fixed to match 
the docs, but since the old behaviour is correct when not accessed via a
symlink and totally blocks access when access would be via a symlink, the only
problem could be if anyone has a symlink to a directory and is relying on it
never working - a somewhat bizarre and relatively unlikely situation.

                                John Line
-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk