httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject Apache 1.1.1 & Options FollowSymLinks - bug? (fwd)
Date Thu, 29 Aug 1996 09:07:31 GMT

Not acked.

(I think he could have said this in one sentence).

----- Forwarded message from WWW server manager -----

From: WWW server manager <webadm@info.cam.ac.uk>
Message-Id: <199608290054.BAA17201@cygnus.csi.cam.ac.uk>
Subject: Apache 1.1.1 & Options FollowSymLinks - bug?
To: apache-bugs@apache.org
Date: Thu, 29 Aug 1996 01:54:10 +0100 (BST)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text

Unless I'm doing something silly ("you are in a maze of twisty config
directives, all different", to mangle a well-known quotation from the
original Adventure game, and it's also nearly 2am), I *think* that Apache
1.1.1 is mishandling Options FollowSymLinks (or rather its absence).

If I'm right, given (a) a document root (and hence entire data hierarchy) in 
which symlinks are enabled in access.conf, and (b) a subsidiary directory which 
is referenced by a symlink from the main data hierarchy, and (c) an access.conf
entry specify Options Index (no others mentioned) for the directory which is 
the target of the symlink in (b), THEN Apache refuses access to the directory 
which is the target of a symlink, even though 
http://www.apache.org/docs/core.html#options implies that FollowSymLinks 
applies (as I thought, which caused major confusion when reality differed)
to whether a link will be followed *from* a directory (needs FollowSymLinks 
enabled), not on whether a symlink can be followed *to* a directory in which 
symlinks are not, as it happens, enabled.

To clarify (perhaps), we have in access.conf (along with other things)

<Directory /data>
Options Indexes FollowSymLinks IncludesNOEXEC
AllowOverride AuthConfig Limit Options
XBitHack Full
order deny,allow
allow from all
</Directory>

<Directory /data/CambUniv/Societies>
AllowOverride None
Options Indexes FollowSymLinks
XBitHack Off
</Directory>

(Nothing else defined which should affect this)

If I remove FollowSymLinks from the Societies directory, I get 
Symbolic link not allowed in the error log; adding FollowSymLinks fixes
it, but I do not *want* symlinks enabled in that directory (or rather, I don't 
want anything other than indexes enabled - the subdirectories of that directory 
contain documents mirrored from a Novell fileserver containing information 
about undergraduate societies, provided by the students...

Since <Directory> sections apply (surprisingly :-) to directory contents,
it doesn't make sense for it to make any difference whether the target of a 
symlink has symlinks enabled - it's the source directory that matters. And the 
documentation agrees with me, though the code seems to differ.

Question: is it me that's wrong, or is the code at least divergent from the 
documentation, if not from your intentions? What's the intended behaviour in 
this situation?


(It was all especially confusing as it happened because the leading "/data" had 
been missing accidentally for some time, from the Societies section. I fixed 
that, and then found I was denied access to the data, even though the section 
that I'd now re-enabled did not contain any access control directives; 
however, at that stage it had "Options Indexes" but did not allow symlinks 
in that directory, the target of the symlink. It was late, and it took me a
while to think to look in the log and find out what it really meant when it
said words to the effect "access denied". Sigh.)

                                John Line

PS Afterthought: it ought not to make any difference, but the directory that 
the symlink is pointing at is a mount point for an automounted (loopback 
from local filesystem outside the server's chroot environment) directory. 
Note that the Solaris 2 automounted does mounts that appear "like the real 
thing", not fudged with symlinks as done by e.g. the amd automounter, hence 
(a) that shouldn't in itself interfere with Apache's symlink checks and (b) 
automounting into a chroot environment works, rather than just giving you 
symlinks to things you cannot access.

-- 
University of Cambridge WWW/gopher server manager account (usually John Line)
Send general queries to the WWW or gopher administrator addresses - 
webmaster@ucs.cam.ac.uk or gopher-admin@ucs.cam.ac.uk.

----- End of forwarded message from WWW server manager -----

-- 
Rob Hartill (robh@imdb.com)
The Internet Movie Database (IMDb)  http://www.imdb.com/
           ...more movie info than you can poke a stick at.

Mime
View raw message